retitle 43787 [AMENDED 07/09/1999] policy on -g, a proposal
thanks
Ok, this is my last attempt for a crowd pleaser. This new an improved
proposal should satisfy any and all complaints (as few as they were). This
new proposal has several added features.
1) Raul was correct in that policy does nto require -g, but it does
suggest it in a major way. So this proposal takes away that huge
suggestion.
2) This proposal gives a suggestion on how to implement the ability to
setup you package to be built with debugging intact, it does not require
this feature.
3) The best part is that most programs that depend on debhelper's dh_strip
will automatically follow this suggestion (except that they will always
build with -g, but atleast it's possible to get non-stripped packages for
custom builds).
This is a non-imposing, non-package-changing-required proposal. I surely
hope that there would be no technical reason to not allow a better
"suggestion" in the policy.
Attached are two files. One containing the current context of this
section (Section 4.1 of the policy manual, version 3.0.1.1). The seconds
is the proposed context. You can diff the two, in order to see what is
changed.
Ben
Generally the following compilation parameters should be used:
CC = gcc
CFLAGS = -O2 -g -Wall # sane warning options vary between programs
LDFLAGS = # none
install -s # (or use strip on the files in debian/tmp)
Note that all installed binaries should be stripped, either by using the
-s flag to install, or by calling strip on the binaries after they have
been copied into debian/tmp but before the tree is made into a package.
The -g flag is useful on compilation so that you have available a full set
of debugging symbols in your built source tree, in case anyone should file
a bug report involving (for example) a core dump.
The -N flag should not be used. On a.out systems it may have been useful
for some very small binaries, but for ELF it has no good effect.
It is up to the package maintainer to decide what compilation options are
best for the package. Certain binaries (such as computationally-intensive
programs) may function better with certain flags (-O3, for example); feel
free to use them. Please use good judgment here. Don't use flags for the
sake of it; only use them 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.
Generally the following compilation parameters should be used:
CC = gcc
CFLAGS = -O2 -Wall # sane warning options vary between programs
LDFLAGS = # none
install -s # (or use strip on the files in debian/tmp)
Note that all installed binaries should be stripped, either by using the
-s flag to install, or by calling strip on the binaries after they have
been copied into debian/tmp but before the tree is made into a package.
The -N flag should not be used. On a.out systems it may have been useful
for some very small binaries, but for ELF it has no good effect.
In some cases it may be useful to be able to build versions of your
package with debugging symbols intact (this depends greatly on the what
type of programming language the package uses, C, C++, Ada, Fortran,
etc.). For most programs, this is done by adding `-g' to the CFLAGS. Note
that since all binaries must be stripped when packaged, having `-g' as a
default flag in the build is not neccessary. If you want users to be able
to rebuild your package with debugging information easily, the suggested
way is to use the ``DEB_BUILD_OPTIONS'' environment variable. The
variable will contain ``debug'' if the build should retain debugging
information. This can be accomplished in the debian/rules file in this
way:
CFLAGS = -O2 -Wall
ifeq (,$(findstring $(DEB_BUILD_OPTIONS),debug DEBUG))
CFLAGS += -g
endif
In order to retain this information in the custom built package, the
binaries should not be stripped (either with "install -s" or using the
strip program). NOTE: This should not be how the package is built by
default, it is merely for convenience to users wishing to debug the
programs in the package, or for you as the maintainer to find problems
when bugs are filed against the package.
It is up to the package maintainer to decide what compilation options are
best for the package. Certain binaries (such as computationally-intensive
programs) may function better with certain flags (-O3, for example); feel
free to use them. Please use good judgment here. Don't use flags for the
sake of it; only use them 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.
