Acknowledgement sent
to Niels Thykier <[email protected]>:
New Bug report received and forwarded. Copy sent to Debian Policy List <[email protected]>.
(Sat, 12 Feb 2011 13:30:07 GMT) (full text, mbox, link).
Subject: debian-policy: please update example in 4.9.1 (debian/rules and
DEB_BUILD_OPTIONS)
Date: Sat, 12 Feb 2011 14:25:40 +0100
Package: debian-policy
Version: 3.9.1.0
Severity: minor
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hey
The example in 4.9.1 suggests to set CFLAGS in a way that completely
overrides values from dpkg-buildpackage/dpkg-buildflags[1]:
CFLAGS = -Wall -g
This will set CFLAGS to "-Wall -g" regardless of what dpkg-buildflags
provides. Possible alternatives that appears to work are:
CFLAGS := $(CFLAGS) -Wall -g
CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -g
While related to #578597, I believe it to be a distinct issue. This was triggered
by this email[2] on debian-mentors.
Thank you in advance,
~Niels
[1] http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options
[2] <[email protected]>
- -- System Information:
Debian Release: 6.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
debian-policy depends on no packages.
debian-policy recommends no packages.
Versions of packages debian-policy suggests:
pn doc-base <none> (no description available)
- -- no debconf information
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBCAAGBQJNVopQAAoJEAVLu599gGRC5owP/126vj5jQDjG+poceq2sMEwY
Pn5Btc+iXey8TLQQoA/0D2pT0VU+dfnflTzQSsiec24R7sSicviEyOujSJDRHsef
zXKriaWLywscP0z8aqGb9z12Fc7zYjYgqeeNc+NLzxoSD+dZRNgo0ILrQ/GQlC7p
Okq1DJnc8BqwFMezxoTk39n+LLTuv6M3OuV7sZYSdHwYNhSVyUjLwppdqTjMMH2j
8qq46PkfvAudj5uskCyY4r7Mh/SSwDYFKMp0Lo/T/ic9WhAZQE+7qu4kjexmtyl/
aTC3c0Tqfc2CSfNoxbRZKY1FUT77ZmBbg17DWRLF8LfajOIkFjK4ps61t9hWNTmX
uGJVzr8m9CNc+HRQAMO4wSTjCDGl3NLnP2d12OiOvhCaFO4nTuUdk+0t8YByUU2P
BPDX0TVmODQT3DPyiIg7lliuyBRk4an4G6SqhrDuMOWQ5iZ4LhxsFZrVE/qlHAeg
IL+5A+AchPKvrDByRKurH09J0wboZt7a2suJfwk+NjyglpYF1X8wwZFxvZN3QlEm
hvPpa2RQRwjfzXE0PIPjjdsdlGCdwNLdooV/O8hBKczw9jaSu6iZyYcFGlgeFXxj
2RhAAWcFqymglZ85uSgmALz7Yq/zawLNU/yOGdajz+Rw+fcfOyINzVQaMIfTjunE
b3kp2V2nF5Sxeg0gKPzZ
=zJ3g
-----END PGP SIGNATURE-----
Acknowledgement sent
to Julien Cristau <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <[email protected]>.
(Sat, 12 Feb 2011 21:33:08 GMT) (full text, mbox, link).
Subject: Re: Bug#613046: debian-policy: please update example in 4.9.1
(debian/rules and DEB_BUILD_OPTIONS)
Date: Sat, 12 Feb 2011 22:32:34 +0100
On Sat, Feb 12, 2011 at 14:25:40 +0100, Niels Thykier wrote:
> Package: debian-policy
> Version: 3.9.1.0
> Severity: minor
>
> Hey
>
> The example in 4.9.1 suggests to set CFLAGS in a way that completely
> overrides values from dpkg-buildpackage/dpkg-buildflags[1]:
>
> CFLAGS = -Wall -g
>
> This will set CFLAGS to "-Wall -g" regardless of what dpkg-buildflags
> provides. Possible alternatives that appears to work are:
>
> CFLAGS := $(CFLAGS) -Wall -g
>
That would be wrong. A package build shouldn't depend on random env
variables.
> CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -g
>
> While related to #578597, I believe it to be a distinct issue. This was triggered
> by this email[2] on debian-mentors.
>
Seems to be the exact same request to me?
Cheers,
Julien
Acknowledgement sent
to Niels Thykier <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <[email protected]>.
(Sat, 12 Feb 2011 22:45:06 GMT) (full text, mbox, link).
Subject: Re: Bug#613046: debian-policy: please update example in 4.9.1 (debian/rules
and DEB_BUILD_OPTIONS)
Date: Sat, 12 Feb 2011 23:38:46 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2011-02-12 22:32, Julien Cristau wrote:
> On Sat, Feb 12, 2011 at 14:25:40 +0100, Niels Thykier wrote:
>
>> Package: debian-policy
>> Version: 3.9.1.0
>> Severity: minor
>>
>> Hey
>>
>> The example in 4.9.1 suggests to set CFLAGS in a way that completely
>> overrides values from dpkg-buildpackage/dpkg-buildflags[1]:
>>
>> CFLAGS = -Wall -g
>>
>> This will set CFLAGS to "-Wall -g" regardless of what dpkg-buildflags
>> provides. Possible alternatives that appears to work are:
>>
>> CFLAGS := $(CFLAGS) -Wall -g
>>
> That would be wrong. A package build shouldn't depend on random env
> variables.
>
I believe a lot of packages in the archive actually suffers from this
issue then, if dpkg-build{package,flags} did not sanitize these variables.
How many packages explicitly sets e.g. LDFLAGS in debian/rules? Almost
none of mine does it (granted most of my packages are Java packages, but
still).
>> CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -g
>>
>> While related to #578597, I believe it to be a distinct issue. This was triggered
>> by this email[2] on debian-mentors.
>>
> Seems to be the exact same request to me?
>
> Cheers,
> Julien
>
Well, yes, if you insist the "CFLAGS := $(CFLAGS) somearg" is wrong, it
would appear that my original request can be trivially be reduced to
#578597.
Though in that case, I think we should change this one to a request to
make the policy be explicit in how a package should handle variables
from the environment (and which variables it should neutralize).
~Niels
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNVwv1AAoJEAVLu599gGRC3twQAIfvAyQRXBN51/aMMDxb3Zyk
dSKdi9OnebvufSULxvgWZJ0pm8+QUp/pjg1FAELGo4tbmFv6jqbW8KIhws3UACtP
TZ9ohwnt/9Hdp3Whvu2gPze0CvKSkplYLtrAMpevvi4S6RN5qX/Un0QtyeD1oNfn
47nJcPINryWZPKKWI6boq1EGed3m2+CIzzjvKtPeQHX/40rgwN39kAZpiuBNGah/
3TiM1/ETZl7oXXxCpJ8EzN62CA3vj6ugSBVCfLFVjlv82sMTV8mZTYaBK2Re8BSu
MHWzb7PHButf3J2xwL1RoaoeuwnJEs+mgP8oFeprf5T4ugjwMbN/FmcxTm2DQlt8
ZbnRFiuBIO/D30TtiW3DAsUcOhZasIcvtRuNZ1U1LFkXj79n4fHsBYIrTdEnbbtR
27lGITVVAHfscZsReIn8Eb3V1uJgklVnQeyMZSpb8wSaKoEVv9uLZPc/NCV9KC41
PahhxuEkTMQfFwCY6cxaeHq/nZwY1XWUYGmHioa0/cPDARyIbwNU2nC6qZNxGCuQ
C5NONW+cTDIqu1S7Hh07B+oRA6MIW8iLZUUdt0kxv0L0ZTawJRk3Kgu7AYPl66CN
cI/n4fNPsAEcPHnMYfk+L+xduO89krrlu38eGAX2a5Z15ZKlaV2NDHlermErcfgg
jsSQKFlYiDiAkjS8hfix
=zUym
-----END PGP SIGNATURE-----
Acknowledgement sent
to Steve Langasek <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <[email protected]>.
(Sun, 13 Feb 2011 01:39:06 GMT) (full text, mbox, link).
On Sat, Feb 12, 2011 at 10:32:34PM +0100, Julien Cristau wrote:
> > CFLAGS := $(CFLAGS) -Wall -g
> That would be wrong. A package build shouldn't depend on random env
> variables.
Depend on, or respect?
Why shouldn't we expect packages to honor extra CFLAGS set in the
environment, and require sanitized environments with no $CFLAGS set for
standard package builds?
(Anyway, isn't setting $CFLAGS in the environment exactly what
dpkg-buildpackage + dpkg-buildflags *does*?)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/[email protected][email protected]
Acknowledgement sent
to Raphael Hertzog <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <[email protected]>.
(Mon, 14 Feb 2011 14:15:07 GMT) (full text, mbox, link).
Subject: Re: Bug#613046: debian-policy: please update example in 4.9.1
(debian/rules and DEB_BUILD_OPTIONS)
Date: Mon, 14 Feb 2011 15:14:04 +0100
Hi,
On Sat, 12 Feb 2011, Steve Langasek wrote:
> On Sat, Feb 12, 2011 at 10:32:34PM +0100, Julien Cristau wrote:
> > > CFLAGS := $(CFLAGS) -Wall -g
>
> > That would be wrong. A package build shouldn't depend on random env
> > variables.
>
> Depend on, or respect?
>
> Why shouldn't we expect packages to honor extra CFLAGS set in the
> environment, and require sanitized environments with no $CFLAGS set for
> standard package builds?
The way to pass supplementary flags is now defined by dpkg-buildflags as
well (and it's DEB_CFLAGS_{APPEND,SET}).
> (Anyway, isn't setting $CFLAGS in the environment exactly what
> dpkg-buildpackage + dpkg-buildflags *does*?)
Yes currently. But dpkg-buildpackage will stop setting the variables and
packages should solely rely on dpkg-buildflags to get the proper values.
That's because most people do not want "debian/rules build" to behave
differently from dpkg-buildpackage.
That said helper tools like "dh" should be free to use dpkg-buildflags
to set environment variables that ./configure and other similar calls
can inspect and use.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Acknowledgement sent
to Julien Cristau <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <[email protected]>.
(Mon, 14 Feb 2011 14:21:08 GMT) (full text, mbox, link).
Subject: Re: Bug#613046: debian-policy: please update example in 4.9.1
(debian/rules and DEB_BUILD_OPTIONS)
Date: Mon, 14 Feb 2011 15:19:27 +0100
On Mon, Feb 14, 2011 at 15:14:04 +0100, Raphael Hertzog wrote:
> That said helper tools like "dh" should be free to use dpkg-buildflags
> to set environment variables that ./configure and other similar calls
> can inspect and use.
>
The usual way to pass CFLAGS to configure is as a command line argument,
not an env var.
Cheers,
Julien
Acknowledgement sent
to Jonathan Nieder <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <[email protected]>.
(Wed, 02 Mar 2011 03:42:03 GMT) (full text, mbox, link).
Subject: Re: debian-policy: please update example in 4.9.1 (debian/rules and
DEB_BUILD_OPTIONS)
Date: Tue, 1 Mar 2011 21:38:36 -0600
user [email protected]
usertags 613046 + informative discussion
quit
Hi,
Julien Cristau wrote:
> On Sat, Feb 12, 2011 at 14:25:40 +0100, Niels Thykier wrote:
>> CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -g
>>
>> While related to #578597, I believe it to be a distinct issue. This was triggered
>> by this email[2] on debian-mentors.
>
> Seems to be the exact same request to me?
I believe they are different. This request seems to be about
informative text (an example), while #578597 is about the normative
part of policy (a policy "should").
Here's a rough patch for discussion's sake. Points that might be nice
to fit in somehow:
- warning flags come before the flags read from dpkg-buildflags,
so they can be overridden with
DEB_CFLAGS_APPEND="-Wno-all -Wno-extra"
- important optimization flags such as -fno-strict-aliasing
come after the flags read from dpkg-buildflags, so they cannot
be overridden
- using := instead of = saves us from running dpkg-buildflags
multiple times if $(CFLAGS) is used more than once.
Thoughts? Improvements?
---
diff --git a/policy.sgml b/policy.sgml
index 242ac10..5814960 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2256,18 +2256,13 @@
massage this example in order to make it work for your
package.
<example compact="compact">
-CFLAGS = -Wall -g
INSTALL = install
INSTALL_FILE = $(INSTALL) -p -o root -g root -m 644
INSTALL_PROGRAM = $(INSTALL) -p -o root -g root -m 755
INSTALL_SCRIPT = $(INSTALL) -p -o root -g root -m 755
INSTALL_DIR = $(INSTALL) -p -d -o root -g root -m 755
-ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
- CFLAGS += -O0
-else
- CFLAGS += -O2
-endif
+CFLAGS := -Wall $(shell dpkg-buildflags --get CFLAGS)
ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
INSTALL_PROGRAM += -s
endif
Acknowledgement sent
to Raphael Hertzog <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <[email protected]>.
(Mon, 30 Jan 2012 14:18:37 GMT) (full text, mbox, link).
Subject: Re: debian-policy: please update example in 4.9.1 (debian/rules and
DEB_BUILD_OPTIONS)
Date: Mon, 30 Jan 2012 15:14:26 +0100
On Fri, 27 Jan 2012, Matthijs Kooijman wrote:
> > -ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
> > - CFLAGS += -O0
> > -else
> > - CFLAGS += -O2
> > -endif
> > +CFLAGS := -Wall $(shell dpkg-buildflags --get CFLAGS)
> > ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
> > INSTALL_PROGRAM += -s
> > endif
>
> Wouldn't it be more appropriate to use
>
> DEB_CFLAGS_MAINT_PREPEND := -Wall
>
> here before calling dpkg-buildflags? Possibly the rest of the example
> could be modified to use DEB_CFLAGS_MAINT_APPEND as well.
Well, they are there so that you can tweak the output of dpkg-buildflags
when the call happens in lower layer and that you have no control over the
call and its output.
And you must take care because $(shell dpkg-buildflags ...) will not see the
DEB_CFLAGS_MAINT_PREPEND that you have set in the rules files. Either you
do $(shell DEB_CFLAGS_MAINT_PREPEND=... dpkg-buildflags ...) or you use
/usr/share/dpkg/buildflags.mk which does the right thing for you.
> Not sure if this is really needed, but it seems to me that that is what
> these variables were invented for :-)
Maybe all the samples from Policy should be simplified to use the Makefile
snippets...
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
Acknowledgement sent
to Matthijs Kooijman <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <[email protected]>.
(Mon, 30 Jan 2012 14:39:14 GMT) (full text, mbox, link).
Hi folks,
just stumbled upon this report, and I have a small suggestion to improve
Jonathan's patch:
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -2256,18 +2256,13 @@
> massage this example in order to make it work for your
> package.
> <example compact="compact">
> -CFLAGS = -Wall -g
> INSTALL = install
> INSTALL_FILE = $(INSTALL) -p -o root -g root -m 644
> INSTALL_PROGRAM = $(INSTALL) -p -o root -g root -m 755
> INSTALL_SCRIPT = $(INSTALL) -p -o root -g root -m 755
> INSTALL_DIR = $(INSTALL) -p -d -o root -g root -m 755
>
> -ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
> - CFLAGS += -O0
> -else
> - CFLAGS += -O2
> -endif
> +CFLAGS := -Wall $(shell dpkg-buildflags --get CFLAGS)
> ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
> INSTALL_PROGRAM += -s
> endif
Wouldn't it be more appropriate to use
DEB_CFLAGS_MAINT_PREPEND := -Wall
here before calling dpkg-buildflags? Possibly the rest of the example
could be modified to use DEB_CFLAGS_MAINT_APPEND as well.
Not sure if this is really needed, but it seems to me that that is what
these variables were invented for :-)
Gr.
Matthijs
Acknowledgement sent
to Russ Allbery <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <[email protected]>.
(Mon, 30 Jan 2012 19:00:03 GMT) (full text, mbox, link).
Subject: Re: Bug#613046: debian-policy: please update example in 4.9.1 (debian/rules and DEB_BUILD_OPTIONS)
Date: Mon, 30 Jan 2012 10:56:09 -0800
Raphael Hertzog <[email protected]> writes:
> Well, they are there so that you can tweak the output of dpkg-buildflags
> when the call happens in lower layer and that you have no control over
> the call and its output.
> And you must take care because $(shell dpkg-buildflags ...) will not see
> the DEB_CFLAGS_MAINT_PREPEND that you have set in the rules
> files. Either you do $(shell
> DEB_CFLAGS_MAINT_PREPEND=... dpkg-buildflags ...) or you use
> /usr/share/dpkg/buildflags.mk which does the right thing for you.
Or you just use:
export DEB_CFLAGS_MAINT_PREPEND = -Wall
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Acknowledgement sent
to Raphael Hertzog <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <[email protected]>.
(Mon, 30 Jan 2012 20:15:04 GMT) (full text, mbox, link).
Subject: Re: Bug#613046: debian-policy: please update example in 4.9.1
(debian/rules and DEB_BUILD_OPTIONS)
Date: Mon, 30 Jan 2012 21:10:24 +0100
On Mon, 30 Jan 2012, Russ Allbery wrote:
> > And you must take care because $(shell dpkg-buildflags ...) will not see
> > the DEB_CFLAGS_MAINT_PREPEND that you have set in the rules
> > files. Either you do $(shell
> > DEB_CFLAGS_MAINT_PREPEND=... dpkg-buildflags ...) or you use
> > /usr/share/dpkg/buildflags.mk which does the right thing for you.
>
> Or you just use:
>
> export DEB_CFLAGS_MAINT_PREPEND = -Wall
No because $(shell ...) only gets environment variable that were existing
at the time make has been invoked. Variables exported by the makefile
itself are not forwarded. :-(
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
Acknowledgement sent
to Russ Allbery <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <[email protected]>.
(Mon, 30 Jan 2012 20:21:06 GMT) (full text, mbox, link).
Subject: Re: Bug#613046: debian-policy: please update example in 4.9.1 (debian/rules and DEB_BUILD_OPTIONS)
Date: Mon, 30 Jan 2012 12:18:07 -0800
Raphael Hertzog <[email protected]> writes:
> No because $(shell ...) only gets environment variable that were
> existing at the time make has been invoked. Variables exported by the
> makefile itself are not forwarded. :-(
Ah, indeed. I didn't realize that.
Using `` instead of $(shell) would of course work, but you have to be
careful about quoting.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Acknowledgement sent
to Charles Plessy <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <[email protected]>.
(Wed, 01 Feb 2012 00:39:03 GMT) (full text, mbox, link).
Subject: Re: Bug#613046: debian-policy: please update example in 4.9.1
(debian/rules and DEB_BUILD_OPTIONS)
Date: Wed, 1 Feb 2012 09:37:20 +0900
Le Fri, Jan 27, 2012 at 01:28:02PM +0100, Matthijs Kooijman a écrit :
> > +CFLAGS := -Wall $(shell dpkg-buildflags --get CFLAGS)
> > ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
> > INSTALL_PROGRAM += -s
> > endif
>
> Wouldn't it be more appropriate to use
>
> DEB_CFLAGS_MAINT_PREPEND := -Wall
Hello everybody,
since §4.9.1's object is to document the DEB_BUILD_OPTIONS, I would find it a
bit dry to only provide an example that works through a tool that is not
mentionned or explained anywhere else in the Policy (see http://bugs.debian.org/578597).
I therfore propose to replace the sentence above it,
The following makefile snippet is an example of how one may implement the
build options; you will probably have to massage this example in order to make
it work for your package.
by:
In the following example, the build options nocheck, nostrip and parallel are
implemented directly in make, and noopt is implemented through its support in
dpkg-buildflags. You will probably have to massage this example in order to
make it work for your package. Note also that other helper tools provide
support for nocheck, nostrip and parallel.
Alternatively, the example could be repaired as proposed in the original,
message or ‘CFLAGS = -Wall -g’ could be simply removed (it is already
recommended somewhere lese), and a mention of dpkg-buildflag's support for
nooopt could be inserted as part of #578597. This would be in line with the
other parts of the Policy and of this example, that focus on the action to
take, not on the helper to use.
By the way, I read in the paragraph describing noopt:
For C programs, it is best to add -O0 to CFLAGS (although this is usually the default).
Isn't that a bit outdated ? I see -O2 or superior in most of my packages.
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Acknowledgement sent
to Russ Allbery <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <[email protected]>.
(Wed, 01 Feb 2012 00:45:03 GMT) (full text, mbox, link).
Subject: Re: Bug#613046: debian-policy: please update example in 4.9.1 (debian/rules and DEB_BUILD_OPTIONS)
Date: Tue, 31 Jan 2012 16:42:37 -0800
Charles Plessy <[email protected]> writes:
> By the way, I read in the paragraph describing noopt:
> For C programs, it is best to add -O0 to CFLAGS (although this is
> usually the default).
> Isn't that a bit outdated ? I see -O2 or superior in most of my
> packages.
This is specifically in the context of implementing the noopt build
option. -O0 explicitly disables gcc optimization. However, gcc does not
optimize by default, so omitting the flag entirely also works. That's the
point of the parenthetical.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Acknowledgement sent
to Jonathan Nieder <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <[email protected]>.
(Wed, 01 Feb 2012 00:45:05 GMT) (full text, mbox, link).
Subject: Re: debian-policy: please update example in 4.9.1 (debian/rules and
DEB_BUILD_OPTIONS)
Date: Tue, 31 Jan 2012 18:43:55 -0600
Hi,
Charles Plessy wrote:
> since §4.9.1's object is to document the DEB_BUILD_OPTIONS, I would find it a
> bit dry to only provide an example that works through a tool that is not
> mentionned or explained anywhere else in the Policy (see http://bugs.debian.org/578597).
> I therfore propose to replace the sentence above it,
>
> The following makefile snippet is an example of how one may implement the
> build options; you will probably have to massage this example in order to make
> it work for your package.
>
> by:
>
> In the following example, the build options nocheck, nostrip and parallel are
> implemented directly in make, and noopt is implemented through its support in
> dpkg-buildflags. You will probably have to massage this example in order to
> make it work for your package. Note also that other helper tools provide
> support for nocheck, nostrip and parallel.
By now I imagine that dpkg-buildflags is becoming enough of a de facto
standard that it would be reasonable to just recommend it with a policy
"should". Niels, would you mind if I merge this with bug#578597?
[...]
> By the way, I read in the paragraph describing noopt:
>
> For C programs, it is best to add -O0 to CFLAGS (although this is usually the default).
>
> Isn't that a bit outdated ? I see -O2 or superior in most of my packages.
I believe the intended meaning is that in many build systems, if you
override CFLAGS and do not specify an optimization level then no
optimization level is passed to gcc, resulting in no optimization.
Thanks,
Jonathan
Acknowledgement sent
to Niels Thykier <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <[email protected]>.
(Wed, 01 Feb 2012 09:36:06 GMT) (full text, mbox, link).
Subject: Re: debian-policy: please update example in 4.9.1 (debian/rules and
DEB_BUILD_OPTIONS)
Date: Wed, 01 Feb 2012 10:34:17 +0100
On 2012-02-01 01:43, Jonathan Nieder wrote:
> Hi,
>
> Charles Plessy wrote:
>
>> [...]
>
> By now I imagine that dpkg-buildflags is becoming enough of a de facto
> standard that it would be reasonable to just recommend it with a policy
> "should". Niels, would you mind if I merge this with bug#578597?
>
> [...]
>
> Thanks,
> Jonathan
Feel free to merge them. :)
~Niels
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.