On Sun, 2002-08-18 at 05:46, Richard Braakman wrote:

> For that matter, there are also Heisenbugs to consider: some bugs only
> appear in the optimized version, not the un-optimized.  Compiling the
> debugging version with different optimization flags would make tracking
> down these bugs needlessly difficult.

Right. I sort of guessed someone might raise this issue, but I wasn't
sure how often it would come up in practise.   

I then propose the following patch.
--- debian-policy-3.5.6.1/policy.sgml   2002-03-14 13:17:48.000000000 -0500
+++ debian-policy-3.5.6.1.hacked/policy.sgml    2002-08-18 18:06:50.000000000 
-0400
@@ -5357,34 +5357,63 @@
          Debugging symbols are useful for error diagnosis,
          investigation of core dumps (which may be submitted by users
          in bug reports), or testing and developing the software.
-         Therefore it is recommended to support building the package
-         with debugging information through the following interface:
-         If the environment variable <tt>DEB_BUILD_OPTIONS</tt>
-         contains the string <tt>debug</tt>, compile the software
-         with debugging information (usually this involves adding the
-         <tt>-g</tt> flag to <tt>CFLAGS</tt>).  This allows the
-         generation of a build tree with debugging information.  If
-         the environment variable <tt>DEB_BUILD_OPTIONS</tt> contains
-         the string <tt>nostrip</tt>, do not strip the files at
-         installation time.  This allows one to generate a package
-         with debugging information included.<footnote>
-           <p>
-             Rationale: Using <tt>-g</tt> by default causes wasted
-             CPU cycles since the information is stripped away
-             anyway; this can have a significant impact on the
-             efficiency of the autobuilders.  Having a standard way
-             to build a debugging variant also makes it easier to
-             build debugging bins and libraries since it provides a
-             documented way of getting this type of build; one does
-             not have to manually edit <tt>debian/rules</tt> or
-             <tt>Makefile</tt>s.
-           </p>
-         </footnote>
+         For this reason, it is recommended to support the
+         standardized environment variable <tt>DEB_BUILD_OPTIONS</tt>.
+         This variable can contain several flags to change how a
+         package is compiled.
+       </p>
+       <p>
+         <taglist>
+           <tag>debug</tag>
+           <item>
+             <p>
+               If this string is present in <tt>DEB_BUILD_OPTIONS</tt>,
+               then ensure that the package is compiled with whatever
+               additional information is necessary for debugging.  For
+               programs written in the C language, this usually means
+               adding <tt>-g</tt> to the <tt>CFLAGS</tt> environment
+               variable.
+             </p>
+           </item>
+           <tag>noopt</tag>
+           <item>
+             <p>
+               The presence of this string means that the package
+               should be complied with the minumum possible amount of
+               optimization.  For C programs, this usually implies
+               adding <tt>-O0</tt> to <tt>CFLAGS</tt>.  Some programs
+               might fail to build or run at this level of
+               optimization; it may be necessary to use <tt>-O1</tt>.
+             </p>
+           </item>
+           <tag>nostrip</tag>
+           <item>
+             <p>
+               This string implies that the debugging symbols should
+               not be stripped from the binary during installation, so
+               that debugging information may be included in the
+               package.
+             </p>
+           </item>
+         </taglist>
+       </p>
+       <p>
+         Rationale: Using <tt>-g</tt> by default causes wasted
+         CPU cycles since the information is stripped away
+         anyway; this can have a significant impact on the
+         efficiency of the autobuilders.  Having a standard way
+         to build a debugging variant also makes it easier to
+         build debugging bins and libraries since it provides a
+         documented way of getting this type of build; one does
+         not have to manually edit <tt>debian/rules</tt> or
+         <tt>Makefile</tt>s.
+       </p>
+       <p>
          The following makefile snippet is an example of how one may
          test for either condition; you will probably have to massage
          this example in order to make it work for your package.
          <example compact="compact">
-CFLAGS = -O2 -Wall
+CFLAGS = -Wall
 INSTALL = install
 INSTALL_FILE    = $(INSTALL) -p    -o root -g root  -m  644
 INSTALL_PROGRAM = $(INSTALL) -p    -o root -g root  -m  755
@@ -5394,12 +5423,16 @@
 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
 CFLAGS += -g
 endif
+ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
+CFLAGS += -O0
+else
+CFLAGS += -O2
+endif
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
 INSTALL_PROGRAM += -s
 endif
          </example>
        </p>
-
        <p>
          It is up to the package maintainer to decide what
          compilation options are best for the package.  Certain




Reply via email to