Re: about dpkg-buildflags

[Raphael Hertzog <hertzog@debian.org>]

On Sun, 28 Mar 2010, Raphael Geissert wrote:
> What do you and the other readers think about that use case?

You are reinventing pkg-config I think. It's not really needed.

> > - which can be overriden/expanded by the user with
> > ~/.config/dpkg-buildflags
> >   (does it make sense to use XDG-compliant config filenames for the home
> >   directory?)
> 
> Not sure. Only very few programs actually use the .config directory.

$ ls /home/rhertzog/.config/|wc -l
30

> > - which can be overriden/expanded by the caller with envionment variables
> >   (DEB_CFLAGS_OVERRIDE / DEB_CFLAGS_APPEND ?)
> 
> I think it would be better for everybody's sake if this is done via command 
> arguments instead of (ab)using env vars. What would those operations do 
> anyway? The caller should just enable or disable a set of groups if it needs 
> to do anything else more than just calling dpkg-buildflags.

command arguments simply don't work. How would you override the build
flags for a single build ?

The scenario here is:
export DEB_CFLAGS_APPEND="-Werror"
dpkg-buildpackage -us -uc

> > dpkg-buildflags will become the official interface that packages should
> > use to retrieve buildflags to use. Whether or not the package use a
> > makefile provided by dpkg doesn't matter, it's only an optional facility
> > that we would provide.
> > 
> > For transition purpose, yes, dpkg-buildpackage should be modified to
> > retrieve the default flags from dpkg-buildflags but the code that exports
> > those variables is bound to be removed in a later release indeed.
> 
> I was thinking it could even be extended beyond build flags (in the strict 
> sense of CFLAGS/CXXFLAGS, etc): configure flags could also be supported.

Why? very few configure flags will work on all packages and those that do
are not those that the user is likely to want to use.

On the other hand, it could be interesting just to let the user insert
a configure flag via the environment variable without having to hand-edit
the source packages. The default/system-provided value for this "flag"
should then be empty.

> The idea was to make it language-independent so that other tools can easily 
> parse them. Having defaults => true/false support would enable some of the 
> features I mentioned above. Architecture-dependent configurations would for 
> example allow the whole hardening-wrapper/includes logic to be moved as 
> dpkg-bf configs (some archs don't correctly support certain features, others 
> produce bogus code, etc).

The default values provided by the vendor can be computed with perl. They
don't have to be stored in configuration files. So we can implement
whatever logic we need.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/