Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>ismail's solution is a common approach, but it suffers from some serious problems. If the user tries to get a debug build by doing './configure --enable-debug', the configure script will set CFLAGS to '-g -O2' and the Makefile will use '-g3 -O0 ... -g -O2' when building any executables. In that case, gcc will use -O2, and some compilers will abort because of the conflicting -O options. Either scenario is not the expected behavior.</p> <p>Building with debug symbols or not is NOT something the project maintainer should worry about at all. This is an issue for the user. If you have a project and you want to make a debug build or a release build, you should use different options at configure time. For example,</p> <pre> $ mkdir debug $ mkdir release $ cd debug && /path/to/configure --prefix=/dbg \ CPPFLAGS=-DDEBUG CXXFLAGS="-g -O0" && make && make install $ cd ../release && /path/to/configure CPPFLAGS=-DNDEBUG && make && make install </pre> <p>This will install a debug build in /dbg/bin and a 'release' install in /usr/local/bin</p> <p>Also, you can greatly reduce the tedium of the necessary typing by using a CONFIG_SITE file. For example, you can do:</p> <pre> echo 'CPPFLAGS=-DDEBUG CFLAGS="-g -O0"' >> /dbg/share/config.site </pre> <p>and then all future invocations of 'configure --prefix=/dbg' will automatically inherit the settings to CPPFLAGS and CFLAGS without needing to be specified on the command line.</p> <p>If, as the package maintainer, you want to provide the user with an easy way to build a "debug release", it is perfectly acceptable to include a script in the distribution that invokes the configure script with the appropriate arguments and invokes <code>make &amp;&amp; make install</code>, but there is absolutely no need to litter your autotool metafiles with such cruft. It simply does not belong there. And be warned, many packages have made attempts to add <code>--enable-debug</code> which are simply wrong. If the user invokes <code>configure CFLAGS="-g -O0"</code> but gets a build that applies unexpected flags then you have a bug and your package is <em>broken</em>. This is an all too common experience, and if you maintain a package (currently thinking about <code>tmux</code> and <code>curl</code>) in which the user does not get what any reasonable person would call a "debug build" after invoking <code>configure CFLAGS="-g -O0"</code>, then your package is <em>broken</em>.</p> <p>An important point that must always be remembered when maintaining a package with the autotools is that the user may be using a completely different tool chain than you are. It is entirely possible that the user's tool chain will require <code>-DMAKE_IT_A_DEBUG</code> or <code>-DUSE_DEBUG</code> or <code>-I/usr/banana-split/debug/build/with/georges/headers</code>. Perhaps it will need <code>-O145</code> or <code>-Q</code> passed to the compiler or <code>-debug</code> passed to the linker, or ... anything. As the maintainer, you simply do not have the information necessary to even make the phrase "debug build" meaningful for all users. So don't try, because you might make the software unbuildable for a certain set of users.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload