[ Sorry if this comes through twice, my Postfix/TLS certificate expired,
and mail stopped working for a bit ]

Here's an updated patch which should address the concerns raised.

--- 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-21 14:58:41.000000000 
-0400
@@ -5332,13 +5332,21 @@
        </p>
 
        <p>
-         Generally the following compilation parameters should be used:
+         By default, when a package is being built, any binaries
+         created should include debugging information, as well as
+         being compiled with optimization.  You should also turn on
+         as many reasonable compilation warnings as possible; this
+         makes life easier for porters, who can then look at build
+         logs for possible problems.  For the C programming language,
+         this means the following compilation parameters should be
+         used:
          <example compact="compact">
 CC = gcc
-CFLAGS = -O2 -Wall # sane warning options vary between programs
+CFLAGS = -O2 -g -Wall # sane warning options vary between programs
 LDFLAGS = # none
 install -s # (or use strip on the files in debian/tmp)
-         </example></p>
+         </example>
+       </p>
 
        <p>
          Note that by default all installed binaries should be stripped,
@@ -5346,60 +5354,67 @@
          <prgn>install</prgn>, or by calling <prgn>strip</prgn> on
          the binaries after they have been copied into
          <tt>debian/tmp</tt> but before the tree is made into a
-         package.</p>
+         package.
+       </p>
 
        <p>
-         The <tt>-N</tt> flag should not be used.  On <tt>a.out</tt>
-         systems it may have been useful for some very small
-         binaries, but for ELF it has no good effect.</p>
-
-       <p>
-         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>
+         Although binaries in the build tree should be compiled with
+         debugging information by default, it can often be difficult
+         to debug programs if they are also subjected to compiler
+         optimization.  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
+         and built.
+       </p>
+       <p>
+         <taglist>
+           <tag>noopt</tag>
+           <item>
+             <p>
+               The presence of this string means that the package
+               should be complied with a minimum of optimization.
+               For C programs, it is best to add <tt>-O0</tt>
+               to <tt>CFLAGS</tt> (although this is usually the
+               default).  Some programs might fail to build or run at
+               this level of optimization; it may be necessary to
+               use <tt>-O1</tt>, for example.
+             </p>
+           </item>
+           <tag>nostrip</tag>
+           <item>
+             <p>
+               This string means 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>
          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.
+         implement the build options; 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 -g
 INSTALL = install
 INSTALL_FILE    = $(INSTALL) -p    -o root -g root  -m  644
 INSTALL_PROGRAM = $(INSTALL) -p    -o root -g root  -m  755
 INSTALL_SCRIPT  = $(INSTALL) -p    -o root -g root  -m  755
 INSTALL_DIR     = $(INSTALL) -p -d -o root -g root  -m  755
 
-ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
-CFLAGS += -g
+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
@@ -5410,7 +5425,9 @@
          if there is good reason to do so.  Feel free to override
          the upstream author's ideas about which compilation
          options are best: they are often inappropriate for our
-         environment.</p></sect>
+         environment.
+       </p>
+      </sect>
 
 
       <sect>

Reply via email to