> On Oct. 14, 2014, 9:06 p.m., Timothy St. Clair wrote:
> > configure.ac, line 281
> > <https://reviews.apache.org/r/26426/diff/1/?file=714874#file714874line281>
> >
> >     Is there a reason you want to leave debug symbols out of optimized 
> > builds?  
> >     
> >     cmake has the pattern correct imho: 
> >     Release
> >     Debug
> >     ReleaseWithDebug
> >     
> >     A ReleaseWithDebug allows packagers, such as myself, to build 
> > w/debugsymbols that are stripped out into a .debuginfo package which can be 
> > used by developers for tracing "When bears attack".  Granted that it is 
> > tenuous debugging at best, but it's better then nothing. 
> >     
> >     So I think we want all three modes, stripping all debug information is 
> > not really idea.
> 
> Cody Maloney wrote:
>     My main motivation is to shrink the size of libmesos. Yesterday sugis in 
> #mesos had one which was 213M. For the buildbot internally, full debian 
> packages (which are compressed) of mesos weign in at 165M a piece (Yes, 
> stripping post-build would help a lot, but why build it to begin with?). Most 
> of this is debug info. Also, we build a bunch of different ways, and when 
> libmesos is as big as it is, a decent amount of time ends up being spent on 
> disk I/O reading / writing all the debug info when we are really just trying 
> to ensure it builds on all the different platforms (Not to mention storage 
> and file size shipping things around the network to centralized repositories).
>     
>     The simple toggle between debug and release, removing the legacy logic 
> gets us most of the benefit.
>     
>     If you have a good place to point me for what is needed to get a 
> 'ReleaseWithDebug' info build up and running I can definitely work on adding 
> that as well.
> 
> Cody Maloney wrote:
>     It is also entirely possible to specify custom CXXFLAGS + CFLAGS with 
> this patch to get the old "optimized debug" build. The flags set by 
> --enable-debug (or not having it), to get back the "optimized debug" build 
> from before.

I suppose rpm builds default CXXFLAGS to '-O2 -g ...', so I can buy the 
argument of just making it easier on the average person.


- Timothy


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26426/#review56573
-----------------------------------------------------------


On Oct. 14, 2014, 11:07 p.m., Cody Maloney wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26426/
> -----------------------------------------------------------
> 
> (Updated Oct. 14, 2014, 11:07 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Timothy St. Clair.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Reworks building mesos in "debug" vs. "release". By default, mesos is now 
> built in release (no debug info, optimized build). If '--enable-debug' is 
> specified to configure, than optimization will be turned off, and debug info 
> will be turned on.
> 
> This also adds a variable 'DEBUG' to the build environment, which people can 
> use in code to see if mesos is built with debugging to enable extra 
> assertions / checks. For release builds we may want to set 'NDEBUG' which 
> removes assert()'s, but that is a seperate discussion.
> 
> Main benefits:
> 1) Getting a build to include/exclude debug information at will is feasible. 
> Before some things like using clang would forcibly enable debug info in all 
> cases
> 2) libmesos.so and the other binaries which get packaged up for use in 
> distributions shrink considerably without manually stripping post-build 
> (Improves build time, makes packaging cleaner)
> 
> 
> Diffs
> -----
> 
>   configure.ac 2b372e06006250b5230956ef096473e98f3fa590 
> 
> Diff: https://reviews.apache.org/r/26426/diff/
> 
> 
> Testing
> -------
> 
> Built with both --enable-debug and without, checking that the flags get 
> passed through correctly.
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Reply via email to