Debian Bug report logs - #578597
Recommend usage of dpkg-buildflags to initialize CFLAGS and al.

version graph

Package: debian-policy; Maintainer for debian-policy is Debian Policy List <debian-policy@lists.debian.org>; Source for debian-policy is src:debian-policy.

Reported by: Raphael Hertzog <hertzog@debian.org>

Date: Wed, 21 Apr 2010 07:15:01 UTC

Severity: wishlist

Merged with 613046

Found in version debian-policy/3.9.1.0

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#578597; Package debian-policy. (Wed, 21 Apr 2010 07:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
New Bug report received and forwarded. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 21 Apr 2010 07:15:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: submit@bugs.debian.org
Subject: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.
Date: Wed, 21 Apr 2010 09:10:54 +0200
Package: debian-policy
Severity: wishlist

With dpkg 1.15.7 just uploaded to sid, there's now a dpkg-buildflags
command that should be used to initialize CFLAGS, LDFLAGS, CPPFLAGS,
FFLAGS, CXXFLAGS. It offers some flexibility for the local admin and for
the user to override/extend the default flags used during a package
compilation.

dpkg-buildpackage continues to export them to not break packages but it
exports the value returned by dpkg-buildflags.

The desired outcome is that all package grab the values directly from
dpkg-buildflags and that we can stop exporting the variables from
dpkg-buildpackage. That way calling debian/rules directly and via
dpkg-buildpackage should give the same result.

Please modify the policy to recommend the usage of dpkg-buildflags (I would
suggest to push that policy change just at the start of squeeze+1).

CFLAGS=$(shell dpkg-buildflags --get CFLAGS)

Note: by using this tool you automatically implement the "noopt" feature
of DEB_BUILD_OPTIONS.

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/




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#578597; Package debian-policy. (Wed, 21 Apr 2010 18:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 21 Apr 2010 18:30:03 GMT) Full text and rfc822 format available.

Message #10 received at 578597@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 578597@bugs.debian.org
Subject: Re: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.
Date: Wed, 21 Apr 2010 13:27:36 -0500
Hi,

Raphael Hertzog wrote:

> With dpkg 1.15.7 just uploaded to sid, there's now a dpkg-buildflags
> command that should be used to initialize CFLAGS, LDFLAGS, CPPFLAGS,
> FFLAGS, CXXFLAGS.

Neat tool; thanks for writing it.

Even without the support of policy, policy already indicates an
obvious reason to use this tool: supporting noopt.

On the other hand, many packages already support the noopt option,
usually with code like the following:

 ifeq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
   CFLAGS = -g -O2
 else
   CFLAGS = -g -O0
 endif

In particular, they override any value of CFLAGS set through the
environment already.

Given that it will probably be a while before this tool is used
universally, what benefit does an existing package with code like the
above get from switching to using dpkg-buildflags?

[...]
> Please modify the policy to recommend the usage of dpkg-buildflags (I would
> suggest to push that policy change just at the start of squeeze+1).
> 
> CFLAGS=$(shell dpkg-buildflags --get CFLAGS)
> 
> Note: by using this tool you automatically implement the "noopt" feature
> of DEB_BUILD_OPTIONS.

In the most common case, yes, this is true.

For this to become policy, I think we’d need to figure out the edge
cases:

 - Some packages cannot build without optimization [1].  What should
   they do?

 - Some packages have been tested to work well with a specific
   optimization preset [2].  How should they specify this?

 - Some packages cannot tolerate certain optimizations [3].  Are they
   required to declare this?

 - Some packages are known to trigger bugs in GCC’s optimizer [4].
   Therefore they should build with optimization.  How to declare
   this?

 - Some build systems do not tolerate warnings (because they check
   stderr or because they use -Werror).  Some compiler flags add
   warnings.  Is this a bug, and should policy mandate any
   preventative measures?

 - Some packages depend on a GCC version older than the current
   default, which might not support all the options that were chosen
   on a system.  Bug?

In the short term, I would be more inclined to see this recommended
through the developer’s reference so we can get some experience
working with it.

Just my two cents,
Jonathan

[1] http://sourceware.org/ml/libc-hacker/2007-10/msg00023.html
[2] zlib uses -O3.
[3] I don’t know if it’s still true, but at some point Qt could
not tolerate strict aliasing.
[4] http://bugs.debian.org/427907




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#578597; Package debian-policy. (Wed, 21 Apr 2010 20:36:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 21 Apr 2010 20:36:09 GMT) Full text and rfc822 format available.

Message #15 received at 578597@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Raphael Hertzog <hertzog@debian.org>, 578597@bugs.debian.org
Subject: Re: Bug#578597: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.
Date: Wed, 21 Apr 2010 20:43:28 +0200
On Wed, Apr 21, 2010 at 09:10:54AM +0200, Raphael Hertzog wrote:
> Package: debian-policy
> Severity: wishlist
> 
> The desired outcome is that all package grab the values directly from
> dpkg-buildflags and that we can stop exporting the variables from
> dpkg-buildpackage. That way calling debian/rules directly and via
> dpkg-buildpackage should give the same result.
> 
> Please modify the policy to recommend the usage of dpkg-buildflags (I would
> suggest to push that policy change just at the start of squeeze+1).
> 
> CFLAGS=$(shell dpkg-buildflags --get CFLAGS)

There should be some documentation about how thoses variables should be used,
whether they should replace or augment the value set by debian/rules, before or
after the upstream makefile change, etc...
Currently it is impossible to use them at all in a reliable way.

For example suppose debian/rules do
CFLAGS="-O2 -Wall -g"
and upstream configure do 
CFLAGS="$CFLAGS -fno-strict-aliasing"
before writing the Makefile so C files are built with
gcc -O2 -Wall -g -fno-strict-aliasing foo.c

Suppose user set CFLAGS to XXX. How C files should build ?
gcc XXX foo.c
gcc XXX -fno-strict-aliasing foo.c
gcc XXX -O2 -Wall -g -fno-strict-aliasing foo.c
gcc XXX -g -fno-strict-aliasing foo.c

Should it depends of some properties of the package, if yes which ?

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#578597; Package debian-policy. (Thu, 22 Apr 2010 06:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 22 Apr 2010 06:51:03 GMT) Full text and rfc822 format available.

Message #20 received at 578597@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Cc: 578597@bugs.debian.org, Raphael Hertzog <hertzog@debian.org>
Subject: Re: Bug#578597: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.
Date: Thu, 22 Apr 2010 08:46:50 +0200
Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:

> On Wed, Apr 21, 2010 at 09:10:54AM +0200, Raphael Hertzog wrote:
>> Package: debian-policy
>> Severity: wishlist
>> 
>> The desired outcome is that all package grab the values directly from
>> dpkg-buildflags and that we can stop exporting the variables from
>> dpkg-buildpackage. That way calling debian/rules directly and via
>> dpkg-buildpackage should give the same result.
>> 
>> Please modify the policy to recommend the usage of dpkg-buildflags (I would
>> suggest to push that policy change just at the start of squeeze+1).
>> 
>> CFLAGS=$(shell dpkg-buildflags --get CFLAGS)
>
> There should be some documentation about how thoses variables should be used,
> whether they should replace or augment the value set by debian/rules, before or
> after the upstream makefile change, etc...
> Currently it is impossible to use them at all in a reliable way.
>
> For example suppose debian/rules do
> CFLAGS="-O2 -Wall -g"
> and upstream configure do 
> CFLAGS="$CFLAGS -fno-strict-aliasing"
> before writing the Makefile so C files are built with
> gcc -O2 -Wall -g -fno-strict-aliasing foo.c
>
> Suppose user set CFLAGS to XXX. How C files should build ?
> gcc XXX foo.c
> gcc XXX -fno-strict-aliasing foo.c
> gcc XXX -O2 -Wall -g -fno-strict-aliasing foo.c
> gcc XXX -g -fno-strict-aliasing foo.c

User knows best and if configure just adds things to CFLAGS then that
can't be avoided in rules. So you should get:

gcc XXX -fno-strict-aliasing foo.c

> Should it depends of some properties of the package, if yes which ?
>
> Cheers,

At the moment you have the following behaviour:

% DEB_CFLAGS_SET=-O0 dpkg-buildflags --get CFLAGS
-O0
% DEB_CFLAGS_APPEND=-Werror dpkg-buildflags --get CFLAGS
-g -O2 -Werror

Maybe setting CFLAGS should behave just like setting DEB_CFLAGS_SET. But
currently that is ignored. Might be a good thing because now you can set
CFLAGS for non-debian sources without interfering with building debian
packages.

MfG
        Goswin

PS: Why can't I do 'eval $(shell dpkg-buildflags --all)'?




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#578597; Package debian-policy. (Thu, 22 Apr 2010 06:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 22 Apr 2010 06:54:03 GMT) Full text and rfc822 format available.

Message #25 received at 578597@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>, 578597@bugs.debian.org
Subject: Re: Bug#578597: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.
Date: Thu, 22 Apr 2010 08:50:23 +0200
On Wed, 21 Apr 2010, Jonathan Nieder wrote:
> On the other hand, many packages already support the noopt option,
> usually with code like the following:
> 
>  ifeq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
>    CFLAGS = -g -O2
>  else
>    CFLAGS = -g -O0
>  endif
> 
> In particular, they override any value of CFLAGS set through the
> environment already.

Yeah, the goal is to replace those snippets with a call to
dpkg-buildflags.

> Given that it will probably be a while before this tool is used
> universally, what benefit does an existing package with code like the
> above get from switching to using dpkg-buildflags?

It will allow users of source packages to experiment more easily with
alternate flags (hardening, -Wall -Werror, etc.).

Note in the answers below all my answers are sample, I'm sure there are
other ways to achieve the same but it was meant to provide a starting
point.

>  - Some packages cannot build without optimization [1].  What should
>    they do?

CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
CFLAGS += -O2

>  - Some packages have been tested to work well with a specific
>    optimization preset [2].  How should they specify this?

CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
ifeq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
    CFLAGS += -O3
endif

>  - Some packages cannot tolerate certain optimizations [3].  Are they
>    required to declare this?
>  - Some build systems do not tolerate warnings (because they check
>    stderr or because they use -Werror).  Some compiler flags add
>    warnings.  Is this a bug, and should policy mandate any
>    preventative measures?

For both of those, I think this is unrelated. The users trying new flags
should certainly expect failures on some packages.

>  - Some packages are known to trigger bugs in GCC’s optimizer [4].
>    Therefore they should build with optimization.  How to declare
>    this?

CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
CFLAGS += -O0

>  - Some packages depend on a GCC version older than the current
>    default, which might not support all the options that were chosen
>    on a system.  Bug?

Huh? I'm fairly sure we're going to be very conservative with the flags
enabled by default on dpkg-buildflags. And in the unlikely case
where this happens, the package maintainer can do a substitution to remove
the offending option if really needed.

> In the short term, I would be more inclined to see this recommended
> through the developer’s reference so we can get some experience
> working with it.

While we certainly need experience, I think the policy is the right place
for documenting this interface. We want an unified interface to control
build flags and the policy is what we use to ensure coherence between
all our packages.

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/




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#578597; Package debian-policy. (Thu, 22 Apr 2010 06:57:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 22 Apr 2010 06:57:05 GMT) Full text and rfc822 format available.

Message #30 received at 578597@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 578597@bugs.debian.org
Subject: Re: Bug#578597: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.
Date: Thu, 22 Apr 2010 08:53:00 +0200
On Wed, 21 Apr 2010, Bill Allombert wrote:
> Suppose user set CFLAGS to XXX. How C files should build ?

Have you read the dpkg-buildflags manual page? If the user wants to modify 
CFLAGS he doesn't set it manually but he uses one of the facility to
extend/override it. The result returned by dpkg-buildflags is supposed to
give the full CFLAGS.

So in your list:
> gcc XXX -fno-strict-aliasing foo.c

Is the right one given XXX=$(shell dpkg-buildflags --get CFLAGS).

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/




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#578597; Package debian-policy. (Thu, 22 Apr 2010 09:42:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 22 Apr 2010 09:42:06 GMT) Full text and rfc822 format available.

Message #35 received at 578597@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: 578597@bugs.debian.org, Raphael Hertzog <hertzog@debian.org>
Subject: Re: Bug#578597: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.
Date: Thu, 22 Apr 2010 11:35:29 +0200
On Thu, Apr 22, 2010 at 08:46:50AM +0200, Goswin von Brederlow wrote:
> Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:
> 
> > On Wed, Apr 21, 2010 at 09:10:54AM +0200, Raphael Hertzog wrote:
> >> Package: debian-policy
> >> Severity: wishlist
> >> 
> >> The desired outcome is that all package grab the values directly from
> >> dpkg-buildflags and that we can stop exporting the variables from
> >> dpkg-buildpackage. That way calling debian/rules directly and via
> >> dpkg-buildpackage should give the same result.
> >> 
> >> Please modify the policy to recommend the usage of dpkg-buildflags (I would
> >> suggest to push that policy change just at the start of squeeze+1).
> >> 
> >> CFLAGS=$(shell dpkg-buildflags --get CFLAGS)
> >
> > There should be some documentation about how thoses variables should be used,
> > whether they should replace or augment the value set by debian/rules, before or
> > after the upstream makefile change, etc...
> > Currently it is impossible to use them at all in a reliable way.
> >
> > For example suppose debian/rules do
> > CFLAGS="-O2 -Wall -g"
> > and upstream configure do 
> > CFLAGS="$CFLAGS -fno-strict-aliasing"
> > before writing the Makefile so C files are built with
> > gcc -O2 -Wall -g -fno-strict-aliasing foo.c
> >
> > Suppose user set CFLAGS to XXX. How C files should build ?
> > gcc XXX foo.c
> > gcc XXX -fno-strict-aliasing foo.c
> > gcc XXX -O2 -Wall -g -fno-strict-aliasing foo.c
> > gcc XXX -g -fno-strict-aliasing foo.c
> 
> User knows best and if configure just adds things to CFLAGS then that
> can't be avoided in rules. So you should get:

Of course it can, it just need to do 
make "CFLAGS=$XXX" 
instead of make to override the CFLAGS.

> gcc XXX -fno-strict-aliasing foo.c

What happen if debian/rules is doing
dh_strip -a --dbg-package=foo-dbg 

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#578597; Package debian-policy. (Thu, 22 Apr 2010 09:54:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 22 Apr 2010 09:54:04 GMT) Full text and rfc822 format available.

Message #40 received at 578597@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 578597@bugs.debian.org
Subject: Re: Bug#578597: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.
Date: Thu, 22 Apr 2010 04:51:23 -0500
Raphael Hertzog wrote:
> On Wed, 21 Apr 2010, Jonathan Nieder wrote:

>> Given that it will probably be a while before this tool is used
>> universally, what benefit does an existing package with code like the
>> above get from switching to using dpkg-buildflags?
>
> It will allow users of source packages to experiment more easily with
> alternate flags (hardening, -Wall -Werror, etc.).
[...]
>>  - Some packages cannot tolerate certain optimizations [3].  Are they
>>    required to declare this?
>>  - Some build systems do not tolerate warnings (because they check
>>    stderr or because they use -Werror).  Some compiler flags add
>>    warnings.  Is this a bug, and should policy mandate any
>>    preventative measures?
>
> For both of those, I think this is unrelated. The users trying new flags
> should certainly expect failures on some packages.

With this caveat the idea makes more sense to me.  Thanks for the
explanation.

Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#578597; Package debian-policy. (Sat, 01 May 2010 11:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 01 May 2010 11:33:03 GMT) Full text and rfc822 format available.

Message #45 received at 578597@bugs.debian.org (full text, mbox):

From: Kurt Roeckx <kurt@roeckx.be>
To: Raphael Hertzog <hertzog@debian.org>, 578597@bugs.debian.org
Subject: Re: Bug#578597: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.
Date: Sat, 1 May 2010 13:31:16 +0200
On Wed, Apr 21, 2010 at 09:10:54AM +0200, Raphael Hertzog wrote:
> Package: debian-policy
> Severity: wishlist
> 
> With dpkg 1.15.7 just uploaded to sid, there's now a dpkg-buildflags
> command that should be used to initialize CFLAGS, LDFLAGS, CPPFLAGS,
> FFLAGS, CXXFLAGS. It offers some flexibility for the local admin and for
> the user to override/extend the default flags used during a package
> compilation.
> 
> dpkg-buildpackage continues to export them to not break packages but it
> exports the value returned by dpkg-buildflags.
> 
> The desired outcome is that all package grab the values directly from
> dpkg-buildflags and that we can stop exporting the variables from
> dpkg-buildpackage. That way calling debian/rules directly and via
> dpkg-buildpackage should give the same result.

Yes, calling debian/rules directly or using dpkg-buildpackage
having the same result is clearly the behaviour we want, which is
something we don't have now.  dpkg-buildflags should be used by
packages just like dpkg-architecture.  So I'm in favour of
recommending it.


Kurt






Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#578597; Package debian-policy. (Sat, 01 May 2010 21:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 01 May 2010 21:45:04 GMT) Full text and rfc822 format available.

Message #50 received at 578597@bugs.debian.org (full text, mbox):

From: Loïc Minier <lool@dooz.org>
To: Raphael Hertzog <hertzog@debian.org>, 578597@bugs.debian.org
Subject: Re: Bug#578597: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.
Date: Sat, 1 May 2010 23:17:23 +0200
        Hey

 Great to this see effort!

On Wed, Apr 21, 2010, Raphael Hertzog wrote:
> The desired outcome is that all package grab the values directly from
> dpkg-buildflags and that we can stop exporting the variables from
> dpkg-buildpackage. That way calling debian/rules directly and via
> dpkg-buildpackage should give the same result.

 I wonder why would we ever want to remove the exports?  To prevent
 accidental pickup of *FLAGS from the env?

> CFLAGS=$(shell dpkg-buildflags --get CFLAGS)

 Would it make sense to recommend:
    CFLAGS ?= $(shell dpkg-buildflags --get CFLAGS)
 instead?

 Or perhaps:
    DEB_CFLAGS_SET ?= $(shell dpkg-buildflags --get CFLAGS)
    [...]
    ./configure CFLAGS="$(DEB_CFLAGS_SET)"

 I see that's not in the man page, not sure it would make sense in
 policy either.

    Thanks
-- 
Loïc Minier




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#578597; Package debian-policy. (Sun, 02 May 2010 06:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 02 May 2010 06:27:06 GMT) Full text and rfc822 format available.

Message #55 received at 578597@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Loïc Minier <lool@dooz.org>
Cc: 578597@bugs.debian.org
Subject: Re: Bug#578597: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.
Date: Sun, 2 May 2010 08:24:42 +0200
Hi,

On Sat, 01 May 2010, Loïc Minier wrote:
> On Wed, Apr 21, 2010, Raphael Hertzog wrote:
> > The desired outcome is that all package grab the values directly from
> > dpkg-buildflags and that we can stop exporting the variables from
> > dpkg-buildpackage. That way calling debian/rules directly and via
> > dpkg-buildpackage should give the same result.
> 
>  I wonder why would we ever want to remove the exports?  To prevent
>  accidental pickup of *FLAGS from the env?

Because they will be useless and induce different behaviour between a raw
debian/rules call and dpkg-buildpackage.

> > CFLAGS=$(shell dpkg-buildflags --get CFLAGS)
> 
>  Would it make sense to recommend:
>     CFLAGS ?= $(shell dpkg-buildflags --get CFLAGS)
>  instead?

IMO no, because we don't want to pickup a value from the environment. If
the user want to alter the flags used by the current build, he should use
the interface offered by dpkg-buildflags (i.e. DEB_CFLAGS_SET/APPEND).

>  Or perhaps:
>     DEB_CFLAGS_SET ?= $(shell dpkg-buildflags --get CFLAGS)
>     [...]
>     ./configure CFLAGS="$(DEB_CFLAGS_SET)"
> 
>  I see that's not in the man page, not sure it would make sense in
>  policy either.

This definitely not, DEB_CFLAGS_SET is for the user not for the maintainer.

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/




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#578597; Package debian-policy. (Sun, 02 May 2010 14:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 02 May 2010 14:18:03 GMT) Full text and rfc822 format available.

Message #60 received at 578597@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: 578597@bugs.debian.org
Subject: Re: Bug#578597: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.
Date: Sun, 2 May 2010 14:14:29 +0000
On Sat, May 01, 2010 at 01:31:16PM +0200, Kurt Roeckx wrote:
> Yes, calling debian/rules directly or using dpkg-buildpackage
> having the same result is clearly the behaviour we want, which is
> something we don't have now.  dpkg-buildflags should be used by
> packages just like dpkg-architecture.  So I'm in favour of
> recommending it.

Agreed on all points.




Forcibly Merged 578597 613046. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Wed, 01 Feb 2012 16:39:07 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 01:55:41 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.