[ros-dev] More RBuild issues...

[Alex Ionescu]

Casper Hornstrup wrote:

>  
>
>>-----Original Message-----
>>From: ros-dev-bounces at reactos.com [mailto:ros-dev-bounces at reactos.com] On Behalf Of Alex Ionescu
>>Sent: 29. maj 2005 20:46
>>To: ReactOS Development List
>>Subject: Re: [ros-dev] More RBuild issues...
>>
>>Ge van Geldorp wrote:
>>
>>    
>>
>>>>From: Casper Hornstrup
>>>>
>>>>Rsym should strip the stabs symbols. What do you need more?
>>>>
>>>>
>>>>        
>>>>
>>>Thinking about it, I believe the difference between the before-rbuild and
>>>after-rbuild situation is that before, stabs symbols would be stripped (for
>>>both DBG := 0 and 1) but rossym symbols (which make the symbolic stack
>>>traceback possible) were only added for DBG := 1. Now, for both DBG := 0 and
>>>1, stabs symbols are stripped but rossym symbols are added even for DBG :=
>>>0. Personally I think this is a good thing, as it will allow testers to
>>>report meaningfull stack traces.
>>>
>>>
>>>      
>>>
>>Testers shouldn't use DBG = 0 builds.... As I've said before...those
>>builds should only be for releasing to the public.
>>They require 64MB of memory to work properly in the first place, are
>>much larger, slower, etc.
>>
>>I know that Casper (and even myself) want bug reports to be sent with
>>meaningful traces, but a 30MB+ memory/disk bloat is not the way to get
>>that. As I've explained before, since we control the releases, I think
>>it's much better for us to run addr2line. Casper says this will mean
>>having hundreds of copies of the symbol files...but I don't see why. We
>>only need one per release. Then Casper says what about users that
>>compile their own versions. But I've always been told that users DON'T
>>compile their own versions, that only "Developers or testers" do. Well,
>>since I've come to agree with that, then it's clear that there isn't any
>>issue with users compiling their own version of ReactOS. As for testers
>>or developers, there's no point in using the release version, since by
>>building from SVN you're not using a "release" anymore, you're using
>>your own build, which has DBG = 1.
>>
>>I hope we can find a compromise.
>>    
>>
>
>Why do I need to use DBG=1? If developers and testers use DBG=1, who will
>test DBG=0?
>  
>
Us, before release. Just like Microsoft tests the "free" build after 
they are done working with the "Checked one"

>People seem to not have a problem allocating 3-4 GB of disk space for their
>Linux system. Why complain over 30MB? 
>
Because it takes people on 56K modems 4 more hours to download the ISO.
Because it makes the installation media much larger; gone is the 
possibility to give off cool looking ROS CDs on those "business card 
sized" CDs or other similar media.
Because I thought our goal was to give the power of Windows to people 
that cannot upgrade anymore because of bad hardware. NT4 worked on 
systems with only 16MB of RAM. Are you saying that we shoudl just scrap 
that and force everyone to use 64MB? There are even developers among us 
who have < 64MB PCs...nevermind the companies and people who would love 
to setup their PC on a system with 32MB of RAM (say an old pentium 
system). You are scrapping all that away and you still don't understand 
my point:

>After 6 years of looking up symbols in
>map files, I'm pretty tired of it and now ReactOS can translate the addresses
>for me. Why would I want to run addr2line for every address? 
>
I *never* said that.

>Why would I want
>to force testers to look them up? 
>
I *never* said that.

>Why wouldn't I want ReactOS to submit a
>bug report containing a stack trace with translated symbols to a mailing list
>when ReactOS has network capability? 
>
I *never* said that.

>The rsym section can be NOLOAD so there
>is no memory bloat.
>  
>
Please elaborate...do we support NOLOAD? Is it marked as NOLOAD? I doubt 
it, because when I boot ReactOS DBG it's using 50MB of memory.

I don't know if you really don't understand what I'm saying, or if 
you're out of arguments and putting things in my mouth. You're making 
this seem as if I just said "developers, I've decided that you shall not 
have symbols anymore!". I am merely pointing out the fact that Windows 
comes with a clear distinction between a FREE build and a CHECKED build, 
and that it is senseless to force the CHECKED build down the throat of 
our users.

Not everyone has a 10MBit connection. Not everyone has a 2GB Dual-Xeon 
system like you do (or is it Quad?). And not everyone are developers! I 
asked to find a compromise, because I too do think that it would be nice 
if user's traces could have the symbols arlready looked up, but killing 
off the potential market just for that is crazy.

If we've decided overnight that our priority is not deprecated/old 
hardware support (which I recall is one of the original goals of 
ReactOS), please let me know, so I can start coding everything in 
C++/VB, allocate 100MB buffers in non-paged pool, and have everything in 
usermode use .NET. That's the direction Microsoft is going. Is this what 
you want our direction to be as well?

I'm merely asking for RELEASE builds to be just that *release* builds. 
You want them to have symbols built-in the files. I'm saying that it 
forces *everyone* to have 64MB computers. I'm asking for a compromise in 
how we can avoid that but still have symbols. I mentionned shipping them 
externally, or having a system that does it automatically online, or 
download them online, or have people use addr2line. All these are 
viable, easy to implement solutions (hint: Microsoft uses all three of 
them and it works great!). You are unwilling to accept any of those 
options and simply speak about how "you" will be inconvienced (you still 
don't understand that you won't, since you'll be using DBG = 1), that is 
not compromise, that is not diplomacy.

I am going to throw one more solution on the table:

A release+debug symbol build for users which have the necessary hardware 
and think they will need it.

Best regards,
Alex Ionescu