On Mon, Sep 06, 1999 at 10:27:28PM -0400, Raul Miller wrote:
> > I'm perfectly willing to have the existing proposal go through. In
> > fact, the additional abstraction may be a good thing, for packages
> > which aren't written in C, and don't use -g for debugging.
> Then again it's at least as easy to provide a DEB_CFLAGS=-g for c
> programs, and a DEB_FOOFLAGS=--glarg for foo programs.
This seems completely rediculous. I could understand DEB_CFLAGS=-g,
and requiring debian/rules to convert -g into whatever's appropriate
for whichever compilers it uses, but having to have a multitude of
different debug variables just because some people might not want to
use GNU Make? Feh.
I'll also note that if you *don't* have GNU make you can do something
like:
debian/makecflags.sh
#!/bin/sh
OPTIMIZE=-O2
DEBUG=
for var in $@; do
case $var in
debug)
DEBUG=-g
;;
warnings)
WARNINGS="-Wall -W"
;;
no-optimize)
OPTIMIZE=-O0
;;
esac
done
echo " $WARNINGS $OPTIMIZE $DEBUG"
(I've extended this to cope with "warnings" and "no-optimize" options too,
just to show you can)
...and make your debian/rules contain something like:
CFLAGS=`makecflags.sh $(DEB_BUILD_OPTS)`
I assume this is legal in just about ever form of make about. If it's not,
at the very worst you can have:
debian/rules
#!/bin/sh
CFLAGS=`makecflags.sh $(DEB_BUILD_OPTS)`
make -f debian/rules.real CFLAGS="$CFLAGS"
or some such.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgpnW05Gt57N1.pgp
Description: PGP signature