Re: Environment variables, debian/rules and dpkg-buildpackage
On Fri, Mar 13 2009, Manoj Srivastava wrote:
>
> There are several things I dislike about the first option.
> 1. I do not like that policy would turn around 15 years of convention
> and suddenly outlaw $(MAKE) -f debian/rules foo. This will break
> many of my packages; and I do not think that that is
> justified. There are better solutions than the ones proposed.
> 2. As a packager, it is easy enough to over ride the setting
> externally, by setting my own variables; but this makes it hard for
> the end user to set the variables. I can certainly see cases where
> one-size-does-not-fit all cases; so making it easy to change the
> flags on a per package, per site, and a per compilation case can be,
> and should be addressed.
> 3. dpkg-buildpackage is probably the wrong place to put this solution
> in.
>
> As a simple, off the cuff design, I can see hewing closer to the
> Gentoo use flags solution, and putting in /etc/debian-build.mk makefile
> snippet, which contains the default setting of the flags.
>
> A) Project wide flags can be set by making that file part of an
> essential package (perhaps dpkg).
> B) The site admin can make any changes they want, like adding SELinux
> or hardening flags in that file. Regular conffile handlig will allow
> site admins to be aware of any project wide changes. This allows
> each site to set variables for that site.
> C) Each package can include that file (-include, so no errors if file
> does not exist), and then override whatever variables they want in a
> package specific variation.
> D) The user can set the variable on the command line, which will
> override the Makefile versions of the variable, for a one off per
> compilation change.
>
> The fact that dpkg-buildpackage's setting the variables is not
> easily configurable, and presents to make as though it was set
> on the commandline, and thus making it hard for the *USER* to set the
> flag variables via env variables, is, in my opinion, a major bug.
>
> Of course, this requires that every package rules file will need
> the -include /etc/debian-build.mk at top, which makes it less than
> ideal, but I am sure we can come up with a better solution.
>
> I consider the issue of being able to set these flags on these
> levels fairly important; if I have missed some use case of where one
> might want to set defaults otherwise (buildd's can set arch specific
> flags just like site admins can), please feel free to point it out.
>
The external file is nice in the fact that it decouples the
installation of the essential package and the rules files; this might
be useful for backported packages as well. In the rules file, one may
check for the presence of the file to be included, and take different
action based on whether it is present or not.
Packages may continue to move over to supporting the common
included file on their own timetable, by just not including the snippet
until the ya re ready. And the snippet may take care of tsome of the
DEB_BUILD_OPTIONS stuff.
So. Here is a little snippet that sets some of the flags (this
is a demo only, I am not setting all the flags here that dpkg sets)
--8<---------------cut here---------------start------------->8---
# set CC to $(DEB_HOST_GNU_TYPE)-gcc only if a cross-build is detected
ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
CC=$(DEB_HOST_GNU_TYPE)-gcc
else
CC = cc
endif
# Policy 10.1 says to make this the default
CFLAGS = -Wall -g
ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
else
CFLAGS += -O2
endif
## ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
## endif
ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
STRIP += -s
LDFLAGS += -s
INT_INSTALL_TARGET = install
else
INT_INSTALL_TARGET = install
endif
ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
MAKEFLAGS += -j$(NUMJOBS)
endif
--8<---------------cut here---------------end--------------->8---
manoj
--
The computing field is always in need of new cliches. Alan Perlis
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: