CMake adoption

You might know me as a stout supporter of CMake transition, but a single experience
shattered my certainity. Today i tried to resolve a backtrace for a bug report, done with
a cmake iso. The results were horrendous.  The backtrace was lenghty, but on rbuild such
task would take around 15 mintues for me, having all files extracted and prepped log.. At
the present moment, cmake bt resolving is a total mess and practically prevents anyone
doing such log. I might not be a programmer, but was somewhat skilled in my testers
duties, also as some recall, i loved doing manual traces by raddr2line. With cmake - i
hate it:

1. the whole process takes minutes more per frame: you need the base address, add the
offset and type in the addr2line command
2. base address from kdbg: mod is not reliable, as modules might be relocated. addr2line
doesn't know about that...
3. C++ function names are not demangled. For those modules that are written in c++ you
will only get source lines, unless you check them up manually.
4. Being somewhat experienced, i see no way how i`m to explain newcomer how to do a
backtrace... on the other hand, do you expect anyone to waste half an hour doing so?

This HAS to be resolved before rbuild is put to retirement. Amine was talking about
getting back to rsym - sure, why not? Anything that works will be better than current
situation.

-- 
With best regards
Caemyr

[Timo Kreuzer]

LOL!

Nothing more to say.

After months you suddenly come up and notice that something doesn't work?
Awesome!

Keep it up people, we'll drop rbuild next year.

...

Sure, no problem. Just tell me how to debug explorer on msvc? Oh, no go?

Its up to you, developers. You can do all by yourself and dont need any assistance from
others, so why bother that some lousy frames will not be traced? As you can expect that in
most cases they wont be. Are you ok with that?

As for months of "not noticing" - you might as well recall that frames in cmake
were supposed to be resolved automagically on its own. Where is it then, Timo?

Best regards

On Saturday, October 08, 2011 7:01 PM, "Timo Kreuzer"
<timo.kreuzer(a)web.de> wrote:
>   LOL!
>  
>  Nothing more to say.
>  
>  After months you suddenly come up and notice that something doesn't work?
>  Awesome!
>  
>  Keep it up people, we'll drop rbuild next year.
>  
>  ...
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>   

-- 
With best regards
Caemyr

[Aleksey Bragin]

Irony is cool ;)

Seriously all Caemyr's points are valid. We can go to a better debug  
format anytime, not specifically at the time of cmake switch.

WBR,
Aleksey.

On Oct 8, 2011, at 9:09 PM, caemyr(a)myopera.com wrote:

>   Sure, no problem. Just tell me how to debug explorer
> on msvc? Oh,  
>  no go?
>
>  Its up to you, developers. You can do all by yourself and dont need  
>  any assistance from others, so why bother that some lousy frames  
>  will not be traced? As you can expect that in most cases they wont  
>  be. Are you ok with that?
>
>  As for months of "not noticing" - you might as well recall that  
>  frames in cmake were supposed to be resolved automagically on its  
>  own. Where is it then, Timo?
>
>  Best regards
>
>  On Saturday, October 08, 2011 7:01 PM, "Timo Kreuzer"  
>  <timo.kreuzer(a)web.de> wrote:
> > LOL!
> >
> > Nothing more to say.
> >
> > After months you suddenly come up and notice that something  
> > doesn't work?
> > Awesome!
> >
> > Keep it up people, we'll drop rbuild next year.
> >
> > ...

[Colin Finck]

Aleksey Bragin <aleksey(a)reactos.org> wrote:
>   Seriously all Caemyr's points are valid. We can go
> to a better debug
>  format anytime, not specifically at the time of cmake switch. 
Then I hope that Amine's r54055 commit message was a bit ironic and 
build doesn't really need twice the disk space with RSYM. Because in 
this case, we get ourselves in another mess and the RAM-Disk on the 
Debug slave will run out of space.

As the current temporary CMake build is performed on the hard disk while 
the RBuild one uses the RAM-Disk, you can easily see that the RAM-Disk 
contributes much to the short build times.

I'm open for any debug format for the CMake switch. I've already made 
the necessary changes to sysreg2 to first look up the base address with 
objdump and then use addr2line instead of using just raddr2line in the past.
This process is fairly scriptable by the way and this has already been 
done, see 
http://svn.reactos.org/svn/reactos/trunk/tools/RosBE-Windows/Root/reladdr2l…
Looks like this was from the time when raddr2line also needed the base 
address.


- Colin

[Colin Finck]

Colin Finck <colin(a)reactos.org> wrote:
>   This process is fairly scriptable by the way and this
> has already been
>  done, see
>
> http://svn.reactos.org/svn/reactos/trunk/tools/RosBE-Windows/Root/reladdr2l…
Correct link: 
http://svn.reactos.org/svn/reactos/trunk/tools/RosBE-Windows/Root/reladdr2l…


- Colin

[Amine Khaldi]

On 09/10/2011 13:44, Colin Finck wrote:
>   Then I hope that Amine's r54055 commit message was
> a bit ironic and 
>  build doesn't really need twice the disk space with RSYM. Because in 
>  this case, we get ourselves in another mess and the RAM-Disk on the 
>  Debug slave will run out of space.  
There was nothing ironic in my commit. Build *does* need twice the disk 
space with RSYM, simply because RSYM needs stabs debug info.. it can't 
work with anything else.

Regards,
Amine.