Re: Bug#544844: status of this bug
(Somehow I think we should move this sub-discussion somewhere else, ccing
debian-dpkg for a start, feel free to drop the bug when replying.
It would also be nice to have the feedback of others on this idea.)
On Mon, 20 Jun 2011, Modestas Vainius wrote:
> I disagree that this is a trend set by debhelper (or dh for that matter). dh
> uses debian/rules for configuration while debhelper uses small files for
> configuration of binary packages. Neither of current small files affect
> building of upstream source itself (which is what truly belongs to
> debian/rules imho).
So maybe that justifies using debian/source/buildflags rather than a file
directly in debian/ (just like debian/source/lintian-overrides). But up to
now debian/source/ was really for stuff affecting/concerning the .dsc so
I'm not sure.
> Anyway, it may not be a bad idea if:
>
> 1) the name was better. .conf at the end is more like gbp.conf than anything
> else dpkg or debhelper currently uses. What's more I would rather prefer
> debian/buildenv, debian/env or something similar as a filename;
buildflags.conf would be consistent with the other files that the tool
uses though. But I'm ok to waive this in particular because of your next
point with the need to support arch/os specific overrides.
> 2) buildflags file was extendable and not limited to predefined set of flags.
> This way it could universably be used to export variables (everything in one
> place), i.e. fully configure build environment (e.g. like CC or CXX in rare
> cases). What's more, support for arch/platform specific buildflags files would
> be nice to have (and maintainers would probably expect this).
You can set new flags in the configuration files already (but you get a
warning). But dpkg-buildflags --list doesn't show them, it's specified
as the flags supported by the current vendor.
I agree that arch/os specific buildflags are sort of required if we want
to offer a way for maintainers to control the buildflags output by
dpkg-buildflags.
> 3) I'm not fond of the syntax but it is just a mere annoyance, nothing more
> severy. I would prefer something more familiar like:
>
> $ cat debian/buildflags
> # append
> CFLAGS += -Wall
> # set
> CXXFLAGS = -g -O3
> # this leaves no obvious way to prepend though
I can understand this but for this I think I'll keep the same syntax than
for the other files. I might add support for a "PREPEND" directive though.
> 4) One of the downsides of this new functionality is that it's a bit too late.
> It is not in squeeze and wheezy is still far away. Therefore I expect its
> adpption to be rather slow. IMHO, it is kind of overkill to add dpkg-dev (>=)
> build-dependency just for this esp. if backports are planned. On the other
> hand, multiarch might indirectly help as then b-d needs to be added anyway.
I think I will provide backports of dpkg because there are several new
functionalities that packages will want to adopt sooner rather than later
(both from dpkg and dpkg-dev).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: