Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Timothy St. Clair]

> On Oct. 14, 2014, 9:06 p.m., Timothy St. Clair wrote:
> > configure.ac, line 281
> > 
> >
> > 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.
> 
> Timothy St. Clair wrote:
> I suppose rpm builds default CXXFLAGS to '-O2 -g ...', so I can buy the 
> argument of just making it easier on the average person.
> 
> Ben Mahler wrote:
> Re-opening because conflating debug and optimization under a single flag 
> seems a bit confusing to me.
> 
> In practice, we run mesos **with optimizations** (for free performance 
> win), and **with debugging symbols** (for meaningful backtraces and core 
> dumps), which was previously the default but now requires the setting of 
> CXXFLAGS to obtain. :(
> 
> For development, I think by default we need debugging symbols turned on. 
> Otherwise most people will forget to configure with `--enable-debug` and 
> consequently will need to recompile everything when they encounter a 
> backtrace or need to debug. CI jobs will encounter this issue as well.
> 
> If there are use cases that merit no debugging symbols, seems nice to 
> make that explicit given it runs the risk of making debugging difficult.
> 
> Thoughts?
> 
> Cody Maloney wrote:
> Note that the two were conflated under one flag previously. This just 
> changes how we do it to be a little more standard way of conflating them. 
> Generally people talk about `Debug` or `Relase` builds. Not the specific 
> compiler flags that get switched. The general switch is -O2 -> -O0 + -g and 
> back (Possibly with a couple extra warning flags). Autotools projects which 
> implement a debug vs. release build almost always do '--enable-debug' / the 
> default is 'optimized' build.
> 
> https://gcc.gnu.org/wiki/DebugFission - that artical has some good 
> explanations why debug info gets problematic as programs get larger and 
> larger, which is only going to get worse over time. Already mesos debug info 
> is over 100MB. As the codebase grows, this will get worse than it already is, 
> increasing the minimum machine specs you need to develop / compile Mesos.
> 
> Compiler implementors generally give that '-O2' should be used to 
> generate an optimal binary. '-g' should be used when you are planning to 
> attach GDB and step through a program line by line. General development 
> generally people want nice backtraces, which is inbetween those. See 
> **Backtraces**. The section **Coredumps** talks about how we can give all the 
> info in coredumps without running full debug builds ('-g') everywhere.
> 
> **Backtraces** should generally be reasonably meaningful as long as you 
> don't strip the binary. Most of the symbols are still there (You just lose 
> inlined things). You don't get file names and line numbers, but all the 
> functions in mesos should be uniquely named (C++'s ODR rule), so you get out 
> a mangled C++ name which you can demangle with `c++filt` (Shipped with GCC) 
> and you will get the full namespace prefixed name of the C++ function. Find 
> the function with your favo

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Cody Maloney]

> On Oct. 14, 2014, 9:06 p.m., Timothy St. Clair wrote:
> > configure.ac, line 281
> > 
> >
> > 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.
> 
> Timothy St. Clair wrote:
> I suppose rpm builds default CXXFLAGS to '-O2 -g ...', so I can buy the 
> argument of just making it easier on the average person.
> 
> Ben Mahler wrote:
> Re-opening because conflating debug and optimization under a single flag 
> seems a bit confusing to me.
> 
> In practice, we run mesos **with optimizations** (for free performance 
> win), and **with debugging symbols** (for meaningful backtraces and core 
> dumps), which was previously the default but now requires the setting of 
> CXXFLAGS to obtain. :(
> 
> For development, I think by default we need debugging symbols turned on. 
> Otherwise most people will forget to configure with `--enable-debug` and 
> consequently will need to recompile everything when they encounter a 
> backtrace or need to debug. CI jobs will encounter this issue as well.
> 
> If there are use cases that merit no debugging symbols, seems nice to 
> make that explicit given it runs the risk of making debugging difficult.
> 
> Thoughts?
> 
> Cody Maloney wrote:
> Note that the two were conflated under one flag previously. This just 
> changes how we do it to be a little more standard way of conflating them. 
> Generally people talk about `Debug` or `Relase` builds. Not the specific 
> compiler flags that get switched. The general switch is -O2 -> -O0 + -g and 
> back (Possibly with a couple extra warning flags). Autotools projects which 
> implement a debug vs. release build almost always do '--enable-debug' / the 
> default is 'optimized' build.
> 
> https://gcc.gnu.org/wiki/DebugFission - that artical has some good 
> explanations why debug info gets problematic as programs get larger and 
> larger, which is only going to get worse over time. Already mesos debug info 
> is over 100MB. As the codebase grows, this will get worse than it already is, 
> increasing the minimum machine specs you need to develop / compile Mesos.
> 
> Compiler implementors generally give that '-O2' should be used to 
> generate an optimal binary. '-g' should be used when you are planning to 
> attach GDB and step through a program line by line. General development 
> generally people want nice backtraces, which is inbetween those. See 
> **Backtraces**. The section **Coredumps** talks about how we can give all the 
> info in coredumps without running full debug builds ('-g') everywhere.
> 
> **Backtraces** should generally be reasonably meaningful as long as you 
> don't strip the binary. Most of the symbols are still there (You just lose 
> inlined things). You don't get file names and line numbers, but all the 
> functions in mesos should be uniquely named (C++'s ODR rule), so you get out 
> a mangled C++ name which you can demangle with `c++filt` (Shipped with GCC) 
> and you will get the full namespace prefixed name of the C++ function. Find 
> the function with your favo

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Cody Maloney]

> On Oct. 14, 2014, 9:06 p.m., Timothy St. Clair wrote:
> > configure.ac, line 281
> > 
> >
> > 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.
> 
> Timothy St. Clair wrote:
> I suppose rpm builds default CXXFLAGS to '-O2 -g ...', so I can buy the 
> argument of just making it easier on the average person.
> 
> Ben Mahler wrote:
> Re-opening because conflating debug and optimization under a single flag 
> seems a bit confusing to me.
> 
> In practice, we run mesos **with optimizations** (for free performance 
> win), and **with debugging symbols** (for meaningful backtraces and core 
> dumps), which was previously the default but now requires the setting of 
> CXXFLAGS to obtain. :(
> 
> For development, I think by default we need debugging symbols turned on. 
> Otherwise most people will forget to configure with `--enable-debug` and 
> consequently will need to recompile everything when they encounter a 
> backtrace or need to debug. CI jobs will encounter this issue as well.
> 
> If there are use cases that merit no debugging symbols, seems nice to 
> make that explicit given it runs the risk of making debugging difficult.
> 
> Thoughts?
> 
> Cody Maloney wrote:
> Note that the two were conflated under one flag previously. This just 
> changes how we do it to be a little more standard way of conflating them. 
> Generally people talk about `Debug` or `Relase` builds. Not the specific 
> compiler flags that get switched. The general switch is -O2 -> -O0 + -g and 
> back (Possibly with a couple extra warning flags). Autotools projects which 
> implement a debug vs. release build almost always do '--enable-debug' / the 
> default is 'optimized' build.
> 
> https://gcc.gnu.org/wiki/DebugFission - that artical has some good 
> explanations why debug info gets problematic as programs get larger and 
> larger, which is only going to get worse over time. Already mesos debug info 
> is over 100MB. As the codebase grows, this will get worse than it already is, 
> increasing the minimum machine specs you need to develop / compile Mesos.
> 
> Compiler implementors generally give that '-O2' should be used to 
> generate an optimal binary. '-g' should be used when you are planning to 
> attach GDB and step through a program line by line. General development 
> generally people want nice backtraces, which is inbetween those. See 
> **Backtraces**. The section **Coredumps** talks about how we can give all the 
> info in coredumps without running full debug builds ('-g') everywhere.
> 
> **Backtraces** should generally be reasonably meaningful as long as you 
> don't strip the binary. Most of the symbols are still there (You just lose 
> inlined things). You don't get file names and line numbers, but all the 
> functions in mesos should be uniquely named (C++'s ODR rule), so you get out 
> a mangled C++ name which you can demangle with `c++filt` (Shipped with GCC) 
> and you will get the full namespace prefixed name of the C++ function. Find 
> the function with your favo

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Ben Mahler]

> On Oct. 14, 2014, 9:06 p.m., Timothy St. Clair wrote:
> > configure.ac, line 281
> > 
> >
> > 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.
> 
> Timothy St. Clair wrote:
> I suppose rpm builds default CXXFLAGS to '-O2 -g ...', so I can buy the 
> argument of just making it easier on the average person.
> 
> Ben Mahler wrote:
> Re-opening because conflating debug and optimization under a single flag 
> seems a bit confusing to me.
> 
> In practice, we run mesos **with optimizations** (for free performance 
> win), and **with debugging symbols** (for meaningful backtraces and core 
> dumps), which was previously the default but now requires the setting of 
> CXXFLAGS to obtain. :(
> 
> For development, I think by default we need debugging symbols turned on. 
> Otherwise most people will forget to configure with `--enable-debug` and 
> consequently will need to recompile everything when they encounter a 
> backtrace or need to debug. CI jobs will encounter this issue as well.
> 
> If there are use cases that merit no debugging symbols, seems nice to 
> make that explicit given it runs the risk of making debugging difficult.
> 
> Thoughts?
> 
> Cody Maloney wrote:
> Note that the two were conflated under one flag previously. This just 
> changes how we do it to be a little more standard way of conflating them. 
> Generally people talk about `Debug` or `Relase` builds. Not the specific 
> compiler flags that get switched. The general switch is -O2 -> -O0 + -g and 
> back (Possibly with a couple extra warning flags). Autotools projects which 
> implement a debug vs. release build almost always do '--enable-debug' / the 
> default is 'optimized' build.
> 
> https://gcc.gnu.org/wiki/DebugFission - that artical has some good 
> explanations why debug info gets problematic as programs get larger and 
> larger, which is only going to get worse over time. Already mesos debug info 
> is over 100MB. As the codebase grows, this will get worse than it already is, 
> increasing the minimum machine specs you need to develop / compile Mesos.
> 
> Compiler implementors generally give that '-O2' should be used to 
> generate an optimal binary. '-g' should be used when you are planning to 
> attach GDB and step through a program line by line. General development 
> generally people want nice backtraces, which is inbetween those. See 
> **Backtraces**. The section **Coredumps** talks about how we can give all the 
> info in coredumps without running full debug builds ('-g') everywhere.
> 
> **Backtraces** should generally be reasonably meaningful as long as you 
> don't strip the binary. Most of the symbols are still there (You just lose 
> inlined things). You don't get file names and line numbers, but all the 
> functions in mesos should be uniquely named (C++'s ODR rule), so you get out 
> a mangled C++ name which you can demangle with `c++filt` (Shipped with GCC) 
> and you will get the full namespace prefixed name of the C++ function. Find 
> the function with your favo

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Cody Maloney]

> On Oct. 14, 2014, 9:06 p.m., Timothy St. Clair wrote:
> > configure.ac, line 281
> > 
> >
> > 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.
> 
> Timothy St. Clair wrote:
> I suppose rpm builds default CXXFLAGS to '-O2 -g ...', so I can buy the 
> argument of just making it easier on the average person.
> 
> Ben Mahler wrote:
> Re-opening because conflating debug and optimization under a single flag 
> seems a bit confusing to me.
> 
> In practice, we run mesos **with optimizations** (for free performance 
> win), and **with debugging symbols** (for meaningful backtraces and core 
> dumps), which was previously the default but now requires the setting of 
> CXXFLAGS to obtain. :(
> 
> For development, I think by default we need debugging symbols turned on. 
> Otherwise most people will forget to configure with `--enable-debug` and 
> consequently will need to recompile everything when they encounter a 
> backtrace or need to debug. CI jobs will encounter this issue as well.
> 
> If there are use cases that merit no debugging symbols, seems nice to 
> make that explicit given it runs the risk of making debugging difficult.
> 
> Thoughts?

Note that the two were conflated under one flag previously. This just changes 
how we do it to be a little more standard way of conflating them. Generally 
people talk about `Debug` or `Relase` builds. Not the specific compiler flags 
that get switched. The general switch is -O2 -> -O0 + -g and back (Possibly 
with a couple extra warning flags). Autotools projects which implement a debug 
vs. release build almost always do '--enable-debug' / the default is 
'optimized' build.

https://gcc.gnu.org/wiki/DebugFission - that artical has some good explanations 
why debug info gets problematic as programs get larger and larger, which is 
only going to get worse over time. Already mesos debug info is over 100MB. As 
the codebase grows, this will get worse than it already is, increasing the 
minimum machine specs you need to develop / compile Mesos.

Compiler implementors generally give that '-O2' should be used to generate an 
optimal binary. '-g' should be used when you are planning to attach GDB and 
step through a program line by line. General development generally people want 
nice backtraces, which is inbetween those. See **Backtraces**. The section 
**Coredumps** talks about how we can give all the info in coredumps without 
running full debug builds ('-g') everywhere.

**Backtraces** should generally be reasonably meaningful as long as you don't 
strip the binary. Most of the symbols are still there (You just lose inlined 
things). You don't get file names and line numbers, but all the functions in 
mesos should be uniquely named (C++'s ODR rule), so you get out a mangled C++ 
name which you can demangle with `c++filt` (Shipped with GCC) and you will get 
the full namespace prefixed name of the C++ function. Find the function with 
your favorite text  editor search, life is happy.

Pretty much every binary which is shipped on your machine via a di

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Ben Mahler]

> On Oct. 14, 2014, 9:06 p.m., Timothy St. Clair wrote:
> > configure.ac, line 281
> > 
> >
> > 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.
> 
> Timothy St. Clair wrote:
> I suppose rpm builds default CXXFLAGS to '-O2 -g ...', so I can buy the 
> argument of just making it easier on the average person.

Re-opening because conflating debug and optimization under a single flag seems 
a bit confusing to me.

In practice, we run mesos **with optimizations** (for free performance win), 
and **with debugging symbols** (for meaningful backtraces and core dumps), 
which was previously the default but now requires the setting of CXXFLAGS to 
obtain. :(

For development, I think by default we need debugging symbols turned on. 
Otherwise most people will forget to configure with `--enable-debug` and 
consequently will need to recompile everything when they encounter a backtrace 
or need to debug. CI jobs will encounter this issue as well.

If there are use cases that merit no debugging symbols, seems nice to make that 
explicit given it runs the risk of making debugging difficult.

Thoughts?


- Ben


---
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
> 
>

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Timothy St. Clair]

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

Ship it!


I'll wait a couple of days for any more comments before a push.

- Timothy St. Clair


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
> 
>

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [26426]

All tests passed.

- Mesos ReviewBot


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
> 
>

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Timothy St. Clair]

> On Oct. 14, 2014, 9:06 p.m., Timothy St. Clair wrote:
> > configure.ac, line 281
> > 
> >
> > 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
> 
>

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Timothy St. Clair]

> On Oct. 14, 2014, 11:11 p.m., Dominic Hamon wrote:
> > configure.ac, line 281
> > 
> >
> > aside: you might want to consider Os for release. It'll keep the size 
> > down and will often be as performant, even without rigourous optimizations, 
> > due to cache friendliness.

You almost always want -O2 over -Os, only typically in embedded situations does 
that change.


- Timothy


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


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
> 
>

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Dominic Hamon]

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



configure.ac


aside: you might want to consider Os for release. It'll keep the size down 
and will often be as performant, even without rigourous optimizations, due to 
cache friendliness.


- Dominic Hamon


On Oct. 14, 2014, 4: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, 4: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
> 
>

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Cody Maloney]

---
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.


Changes
---

Switch to yes/no


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 (updated)
-

  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

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Cody Maloney]

> On Oct. 14, 2014, 9:06 p.m., Timothy St. Clair wrote:
> > configure.ac, line 281
> > 
> >
> > 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.

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.


- Cody


---
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
> 
>

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Cody Maloney]

> On Oct. 14, 2014, 9:06 p.m., Timothy St. Clair wrote:
> > configure.ac, line 281
> > 
> >
> > 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.

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


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


On Oct. 7, 2014, 10:38 p.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26426/
> ---
> 
> (Updated Oct. 7, 2014, 10:38 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 da1c82db31583fc81de658574b9a95628cb84dbc 
> 
> 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
> 
>

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Timothy St. Clair]

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



configure.ac


Typical pattern is yes/no vs. true/false. 
Not that it really matters, more for consistency.



configure.ac


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.


- Timothy St. Clair


On Oct. 7, 2014, 10:38 p.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26426/
> ---
> 
> (Updated Oct. 7, 2014, 10:38 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 da1c82db31583fc81de658574b9a95628cb84dbc 
> 
> 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
> 
>

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [26426]

All tests passed.

- Mesos ReviewBot


On Oct. 7, 2014, 10:38 p.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26426/
> ---
> 
> (Updated Oct. 7, 2014, 10:38 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 da1c82db31583fc81de658574b9a95628cb84dbc 
> 
> 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
> 
>