Re: [gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

Re: [gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

On 07/01/2010 02:25 AM, Jeremy Olexa wrote:
> On Wed, 30 Jun 2010 17:09:00 +0200, "Diego E. 'Flameeyes'" Pettenò
> <flameeyes@gentoo.org> wrote:
> 
>> Please check the linked documentation or my blog post[1] on the matter
>> if you want to understand the reasoning. I'll be dropping the flag and
>> its context from now on if I stumble across it, without further
>> warnings.
> 
> Hey Diego, (not sure if you are on -dev list or not, therefore adding
> you to cc)
> 
> What is the consensus on if the metadata.xml specifies that it will add
> CFLAGS? Surely it is not as black/white as the global suggests..?
> 
> local:debug:app-portage/eix: Build with CXXFLAGS/LDFLAGS for debugging
> support; not recommended for normal use.
> 

I think metadata.xml descriptions should only be used to be more
detailed than the global meaning. One criteria for being a global use
flag is that the flag means the same across packages.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

On 6/30/10 5:09 PM, Diego E. 'Flameeyes' Pettenò wrote:
> Please check the linked documentation or my blog post[1] on the
> matter if you want to understand the reasoning.

Could you rather add these guidelines to the QA project webpage? I
wouldn't consider a blog post a documentation of a policy that people
should follow.

> I'll be dropping the flag and its context from now on if I stumble
> across it, without further warnings.

Please document it in a proper way before enforcing it. Also, a repoman
check or portage check catching at least some of the misuses would be great.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 683 bytes --]

On Wednesday, June 30, 2010 19:25:32 Jeremy Olexa wrote:
> On Wed, 30 Jun 2010 17:09:00 +0200, "Diego E. 'Flameeyes'" Pettenò wrote:
> > Please check the linked documentation or my blog post[1] on the matter
> > if you want to understand the reasoning. I'll be dropping the flag and
> > its context from now on if I stumble across it, without further
> > warnings.
> 
> What is the consensus on if the metadata.xml specifies that it will add
> CFLAGS? Surely it is not as black/white as the global suggests..?
> 
> local:debug:app-portage/eix: Build with CXXFLAGS/LDFLAGS for debugging
> support; not recommended for normal use.

eix is broken and needs fixing
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Jeremy Olexa]

On Wed, 30 Jun 2010 17:09:00 +0200, "Diego E. 'Flameeyes'" Pettenò
<flameeyes@gentoo.org> wrote:

> Please check the linked documentation or my blog post[1] on the matter
> if you want to understand the reasoning. I'll be dropping the flag and
> its context from now on if I stumble across it, without further
> warnings.

Hey Diego, (not sure if you are on -dev list or not, therefore adding
you to cc)

What is the consensus on if the metadata.xml specifies that it will add
CFLAGS? Surely it is not as black/white as the global suggests..?

local:debug:app-portage/eix: Build with CXXFLAGS/LDFLAGS for debugging
support; not recommended for normal use.

Thanks,
Jeremy

[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

On Wed, 30 Jun 2010 23:25:32 +0000
Jeremy Olexa <darkside@gentoo.org> wrote:

> What is the consensus on if the metadata.xml specifies that it will add
> CFLAGS? Surely it is not as black/white as the global suggests..?
> 
> local:debug:app-portage/eix: Build with CXXFLAGS/LDFLAGS for debugging
> support; not recommended for normal use.

USE flags should not affect CFLAGS unless there is a very good reason.  This
isn't a very good reason (same goes for its optimization and
strong-optimization flags).

I have a half-done compiler flag policy thingy i keep meaning to finish
and post for public thrashing.


-- 
fonts, gcc-porting,                                   and it's all by design
toolchain, wxwidgets                        to keep us from losing our minds
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Vaeth]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3033 bytes --]

(Sorry that this mail does not contain the proper "References:";
I am not a regular reader of this list and therefore cannot "reply").

Ryan Hill <dirtyepic@gentoo.org> wrote:

> USE flags should not affect CFLAGS unless there is a very good reason

A valid reason should be that upstream would prefer to add these flags.

Please note that usually upstream should know best which CFLAGS
to add, because upstream is usually the only instance fully familiar
with all details of the code (at least, upstream _should_ be so :) ).
In fact, a lot of flags are not only safe to add but really *should*
be added if the code was written with such flags in mind.

For instance, if the code contains no type-punning, -fstrict-aliasing
can be safely added, and it would be a waste of upstream's effort to
possibly avoid type-punning if it is not added in such a case.
Another example is -fmerge-all-constants where usually code is written
having in mind that optimizations due to this flag will happen
(e.g. certain constants are sometimes redundantly repeated in the
source [for convenience or possibly local change] instead of making
sure that they occur only once).

In fact, most CFLAGS are there for a reason (adding them is only
"ricing" if you do it without respecting details of the code).

So who should add the CFLAGS appropriate for a particular package?
The user cannot do it seriously for every package separately (this
option is reasonable only for binary distributions).
Some packages try to force CFLAGS on the user without asking, but
this is not very good, because the user might have a valid reason to
disagree with upstream's decisions. For instance, a flag might be
broken in a particular compiler version.

So the natural thing is to give the user the choice whether to follow
upstream's recommendations or not. And the way of choice in gentoo is
usually done by USE flags. I would consider it very strange if
a _purely political_ decision would forbid convenient choices for
user and upstream.

The debug USE flag in eix is also about convenience for the user:
If eix segfaults, it prints instructions how to produce a backtrace
in such a way which is most likely useful for upstream to locate
the problem.
Currently, these instructions are rather simple, because they can
refer to USE=debug. Omitting the debug USE flag would complicate
the instructions, making debugging less convenient for the user
and for upstream. Why should such an inconvenience be necessary?
Only to follow some abstract fundamental policy about what USE flags
are allowed to do?  If this is really the case then perhaps there is
something wrong with that policy.

To avoid a misunderstanding: For packages for which upstream has no
particular preference for the CFLAGS, I agree that it would be very
strange to add CFLAGS by means of a USE flag. But if there _is_ such
a recommendation, I would not like to see it ignored in Gentoo
just for political reasons.

Best Regards
Martin Väth

Re: [gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 935 bytes --]

On Thursday, July 01, 2010 08:53:19 Vaeth wrote:
> The debug USE flag in eix is also about convenience for the user:
> If eix segfaults, it prints instructions how to produce a backtrace
> in such a way which is most likely useful for upstream to locate
> the problem.
> Currently, these instructions are rather simple, because they can
> refer to USE=debug. Omitting the debug USE flag would complicate
> the instructions, making debugging less convenient for the user
> and for upstream. Why should such an inconvenience be necessary?
> Only to follow some abstract fundamental policy about what USE flags
> are allowed to do?  If this is really the case then perhaps there is
> something wrong with that policy.

this is in no way specific to eix.  if you want convenience, design a real 
solution common to *all* packages and post it to the list.  
arbitrary/inconsistent hacks utilizing USE=debug is wrong.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 3310 bytes --]

On Thu, 1 Jul 2010 14:53:19 +0200 (CEST)
Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:

> (Sorry that this mail does not contain the proper "References:";
> I am not a regular reader of this list and therefore cannot "reply").
> 
> Ryan Hill <dirtyepic@gentoo.org> wrote:
> 
> > USE flags should not affect CFLAGS unless there is a very good reason
> 
> A valid reason should be that upstream would prefer to add these flags.
> 
> Please note that usually upstream should know best which CFLAGS
> to add, because upstream is usually the only instance fully familiar
> with all details of the code (at least, upstream _should_ be so :) ).
> In fact, a lot of flags are not only safe to add but really *should*
> be added if the code was written with such flags in mind.
>
> [...]

Upstream is free to use whatever CFLAGS they see fit, as long as the user has
the option of disabling them.  This is simply done by appending the user's
CFLAGS to those of the build system.  But this has nothing to do with USE
flags.

> So the natural thing is to give the user the choice whether to follow
> upstream's recommendations or not. And the way of choice in gentoo is
> usually done by USE flags.

USE flags control package options - whether to include support for foo,
install extra documentation, build against either of lib-a or lib-b, etc.
They should not affect compiler flags.  Some exceptions are pch, profiling,
and critical packages that really, really should be built with upstream's
compiler flags but then people whine so much about "Gentoo being about choice"
that someone adds a "custom-cflags" USE.

The way to control compiler flags in Gentoo is CFLAGS.

> The debug USE flag in eix is also about convenience for the user:
> If eix segfaults, it prints instructions how to produce a backtrace
> in such a way which is most likely useful for upstream to locate
> the problem.
> Currently, these instructions are rather simple, because they can
> refer to USE=debug. Omitting the debug USE flag would complicate
> the instructions, making debugging less convenient for the user
> and for upstream. Why should such an inconvenience be necessary?

If all --enable-debug does is add -g to CFLAGS, why can't you just say that?
Or maybe point them to http://www.gentoo.org/proj/en/qa/backtraces.xml?

If --enable-debug does more than that then having a debug USE flag is
perfectly fine.  I don't have a problem with --enable-debug adding -g as well
as (eg.) enabling assertions because if you're using USE="debug" you're
probably using -g already.

> To avoid a misunderstanding: For packages for which upstream has no
> particular preference for the CFLAGS, I agree that it would be very
> strange to add CFLAGS by means of a USE flag. But if there _is_ such
> a recommendation, I would not like to see it ignored in Gentoo
> just for political reasons.

Again, we're not ignoring CFLAGS and we're not doing this for abstract or
political reasons.  This simply isn't what the debug USE flag is for.


-- 
fonts, gcc-porting,                                   and it's all by design
toolchain, wxwidgets                        to keep us from losing our minds
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Nikos Chantziaras]

On 07/01/2010 11:00 PM, Ryan Hill wrote:
>[...]
> The way to control compiler flags in Gentoo is CFLAGS.

That is true.  However, there's a problem; you can control package 
options of individual packages with USE flags, but you can't control 
compilation switches of individual packages with CFLAGS.  This will 
naturally make people feel like using USE flags to modify compilation 
options is a good idea.

Surely, one has to sympathize with this mindset even though it's a wrong 
thing to do.

Re: [gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Alec Warner]

On Thu, Jul 1, 2010 at 1:04 PM, Nikos Chantziaras <realnc@arcor.de> wrote:
> On 07/01/2010 11:00 PM, Ryan Hill wrote:
>>
>> [...]
>> The way to control compiler flags in Gentoo is CFLAGS.
>
> That is true.  However, there's a problem; you can control package options
> of individual packages with USE flags, but you can't control compilation
> switches of individual packages with CFLAGS.  This will naturally make
> people feel like using USE flags to modify compilation options is a good
> idea.

If you use portage than you can control per-package CFLAGS using
bashrc and /etc/portage/env or similar functionality.  I am unsure if
other package managers support this behavior or not.

-A

>
> Surely, one has to sympathize with this mindset even though it's a wrong
> thing to do.
>
>
>

[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Vaeth]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2270 bytes --]

Ryan Hill <dirtyepic@gentoo.org> wrote:
> Upstream is free to use whatever CFLAGS they see fit, as long as the
> user has the option of disabling them.  This is simply done by appending
> the user's CFLAGS to those of the build system.

Since it is obvious that by _appending_ only the user's CFLAGS to your
own, you do not give him the option of disabling your own, the more
natural way to do this is to make it configurable in the build system,
e.g. by a ./configure option.

> But this has nothing to do with USE flags.

The usual way in gentoo to pass upstream's ./configure options
to the user is via USE flags.

> USE flags control package options

And in a case as the described, the CFLAGS become part of the package
options (at least what upstream considers as package options).

> The way to control compiler flags in Gentoo is CFLAGS.

CFLAGS in Gentoo are the way to pass CFLAGS to the build system.
Nothing more, nothing less.
You want to make it the _only_ way to control compiler flags.
Since Gentoo is lacking any other mechanism allowing an ebuild author
or upstream to set default CFLAGS (binary distributions do not need
such things, because the packager should compile the package with the
appropriate flags anyway), this would mean _in practice_:
Either upstreams forces its flags upon the user, or most users will
*not* build the package according to the package authors' suggestions
(and most will probably not even realize this).
You cannot seriously believe that one of these possibilities is better
than to make the things transparent to the user and to give him
the choice _in practice_ by means of a USE flag.

> If --enable-debug does more than that then having a debug USE flag is
> perfectly fine.  I don't have a problem with --enable-debug adding -g
> as well as (eg.) enabling assertions

This is one of the things which are happening. More precisely,
not disabling assertions by *not* adding -DNDEBUG (and e.g. not
breaking code by not adding -flto with the -g).
Admittedly, it is not overly complex what USE=debug does, but -
well, it enables the only debugging support which is available
which in this case is all related with CFLAGS in some way or
another.

Best Regards
Martin Väth

[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Vaeth]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1098 bytes --]

Nikos Chantziaras <realnc@arcor.de> wrote:
>
> If you use portage than you can control per-package CFLAGS using
> bashrc and /etc/portage/env or similar functionality.

This is correct, but the problem is that an ebuild author or
upstream cannot set a "default" here:  IMHO, it shouldn't be
necessary for the user to use such things only in order to
compile a package with the CFLAGS which upstream recommends.
Normally, users will not read such a recommendation (and in fact,
they shouldn't have to, since reading INSTALL or similar things
should be the task of the ebuild author).

Speaking from the author's perspective: There should be a way
to write code appropriate for a specific compiler flag and to
assume that most users will then actually compile the package
with the corresponding flag.
If a user explicitly does not want to do this, this is fine,
but the ebuild should have a way to make sure that this only
happens if it is really the intention of the user.
Normally, USE flags are the way to pass options to the
user, aren't they?

Best Regards
Martin Väth

Re: [gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Alec Warner]

On Thu, Jul 1, 2010 at 3:14 PM, Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
> Nikos Chantziaras <realnc@arcor.de> wrote:
>>
>> If you use portage than you can control per-package CFLAGS using
>> bashrc and /etc/portage/env or similar functionality.
>
> This is correct, but the problem is that an ebuild author or
> upstream cannot set a "default" here:  IMHO, it shouldn't be
> necessary for the user to use such things only in order to
> compile a package with the CFLAGS which upstream recommends.
> Normally, users will not read such a recommendation (and in fact,
> they shouldn't have to, since reading INSTALL or similar things
> should be the task of the ebuild author).

I am confused.  If you want the users to use a default set of CFLAGS
you should set this in your build system (autotools, cmake, whatever).

http://www.mail-archive.com/autoconf@gnu.org/msg14303.html

I believe the above link seems to describe what you are looking to do
using autotools.  Obviously if a user specifies a flag that over-rides
your own flags; the user's flags will take precedence.  However this
is intentional behavior.  I could totally be misunderstanding
autotools as well; I haven't written any in about four years.

-A

>
> Speaking from the author's perspective: There should be a way
> to write code appropriate for a specific compiler flag and to
> assume that most users will then actually compile the package
> with the corresponding flag.
> If a user explicitly does not want to do this, this is fine,
> but the ebuild should have a way to make sure that this only
> happens if it is really the intention of the user.
> Normally, USE flags are the way to pass options to the
> user, aren't they?
>
> Best Regards
> Martin Väth
>

[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 3935 bytes --]

On Thu, 1 Jul 2010 23:44:17 +0200 (CEST)
Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:

> Ryan Hill <dirtyepic@gentoo.org> wrote:
> > Upstream is free to use whatever CFLAGS they see fit, as long as the
> > user has the option of disabling them.  This is simply done by appending
> > the user's CFLAGS to those of the build system.
> 
> Since it is obvious that by _appending_ only the user's CFLAGS to your
> own, you do not give him the option of disabling your own, the more
> natural way to do this is to make it configurable in the build system,
> e.g. by a ./configure option.

> Speaking from the author's perspective: There should be a way
> to write code appropriate for a specific compiler flag and to
> assume that most users will then actually compile the package
> with the corresponding flag.
> If a user explicitly does not want to do this, this is fine,
> but the ebuild should have a way to make sure that this only
> happens if it is really the intention of the user.

If your build system sets -ffast-math or -fstrict-aliasing then the user can
disable this by setting -fno-fast-math or -fno-strict-aliasing in their
CFLAGS.  If they don't, your flags are used.  Isn't this exactly what you're
asking for?

> > But this has nothing to do with USE flags.
> 
> The usual way in gentoo to pass upstream's ./configure options
> to the user is via USE flags.

Just because you've chosen to make compiler flags controlled by configure
options in your package does not mean they should be USE flags.

> > The way to control compiler flags in Gentoo is CFLAGS.
> 
> CFLAGS in Gentoo are the way to pass CFLAGS to the build system.
> Nothing more, nothing less.
> You want to make it the _only_ way to control compiler flags.
> Since Gentoo is lacking any other mechanism allowing an ebuild author
> or upstream to set default CFLAGS (binary distributions do not need
> such things, because the packager should compile the package with the
> appropriate flags anyway), this would mean _in practice_:
> Either upstreams forces its flags upon the user, or most users will
> *not* build the package according to the package authors' suggestions
> (and most will probably not even realize this).
> You cannot seriously believe that one of these possibilities is better
> than to make the things transparent to the user and to give him
> the choice _in practice_ by means of a USE flag.

I honestly don't understand what you're talking about.  You're not making
sense.  Set your CFLAGS in your build system.  If people need to override
them they can specifically do so.  Otherwise your options will be used, like
you want.

If you feel so strongly that your upstream-chosen-and-approved flags should
always be used then add a "custom-cflags" USE flag and call strip-flags if
it's disabled.  While this is strongly discouraged, it's ultimately up to the
maintainer to decide to use it.

> > If --enable-debug does more than that then having a debug USE flag is
> > perfectly fine.  I don't have a problem with --enable-debug adding -g
> > as well as (eg.) enabling assertions
> 
> This is one of the things which are happening. More precisely,
> not disabling assertions by *not* adding -DNDEBUG (and e.g. not
> breaking code by not adding -flto with the -g).
> Admittedly, it is not overly complex what USE=debug does, but -
> well, it enables the only debugging support which is available
> which in this case is all related with CFLAGS in some way or
> another.

Then what are we arguing about? :)  -DNDEBUG is not a CFLAG, it's a
preprocessor definition and is a perfectly valid reason for a debug USE flag.

-- 
fonts, gcc-porting,                                   and it's all by design
toolchain, wxwidgets                        to keep us from losing our minds
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

On Thu, 01 Jul 2010 23:04:10 +0300
Nikos Chantziaras <realnc@arcor.de> wrote:

> On 07/01/2010 11:00 PM, Ryan Hill wrote:
> >[...]
> > The way to control compiler flags in Gentoo is CFLAGS.
> 
> That is true.  However, there's a problem; you can control package 
> options of individual packages with USE flags, but you can't control 
> compilation switches of individual packages with CFLAGS.  This will 
> naturally make people feel like using USE flags to modify compilation 
> options is a good idea.
> 
> Surely, one has to sympathize with this mindset even though it's a wrong 
> thing to do.

We've had per-package CFLAGS for quite a long time now.  Maybe we need to
advertise this a little more?  There would certainly be a market for some
util to manage all the per-package options that we have scattered around in
different config files.


-- 
fonts, gcc-porting,                                   and it's all by design
toolchain, wxwidgets                        to keep us from losing our minds
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Duncan]

Ryan Hill posted on Thu, 01 Jul 2010 19:48:49 -0600 as excerpted:

> We've had per-package CFLAGS for quite a long time now.  Maybe we need
> to advertise this a little more?  There would certainly be a market for
> some util to manage all the per-package options that we have scattered
> around in different config files.

The answer has always been that various devs are afraid of publicizing the 
env dir, particularly since settings there are not directly exposed via 
emerge --info, because it'd make bugs rather more difficult to trace due 
to the hidden settings.

Is that fixed yet?  Because I've always thought it was a useful tool too 
few knew about, as well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Vaeth]

Ryan Hill <dirtyepic@gentoo.org> wrote:

> If your build system sets -ffast-math or -fstrict-aliasing
> then the user can disable this by setting -fno-fast-math
> or -fno-strict-aliasing in their CFLAGS.

Just because some flags have "counter"-flags by accident,
this does not hold for all flags. It is more reasonable to have
other means that the flags are not modified in the first place.
In fact, when I first introduced adding of CFLAGS, there were
lot of complaints that this is evil and must not be done.
I can understand this point of view (even if I know that
certain CFLAGS should be used with the code and I would also
prefer to have them to find possibly hidden bugs), so we
compromised by having an option:
With this option everybody could live well, since users with
special settings will not run into trouble because undesired
flags are added, and other users could just select the USE flag
and have the benefits of appropriately optimized code.
Up to now, that is, when we have this IMHO needless discussion
that an option should not be an option.

I hope that this answers also the question of
Alec Warner <antarus@gentoo.org>:

: I am confused.  If you want the users to use a default set of CFLAGS
: you should set this in your build system (autotools, cmake, whatever).
: [...]
: I believe the above link seems to describe what you are looking to do
: using autotools.

Technically, I have no problem to force in configure.ac that certain
CFLAGS are used (unless somebody patches the configure.ac, of course).
The problem is that it is not good to force this if the user disagrees
(or maybe even unless he explicitly agrees), i.e. it should be an
option which the user really has. (If this option should only be
documented in some INSTALL text or in the ./configure output,
most users do not really have this option, because they would not
even know about it.)

Best Regards
Martin

[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 3182 bytes --]

On Fri, 2 Jul 2010 15:29:44 +0200 (CEST)
Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:

> Ryan Hill <dirtyepic@gentoo.org> wrote:
> 
> > If your build system sets -ffast-math or -fstrict-aliasing
> > then the user can disable this by setting -fno-fast-math
> > or -fno-strict-aliasing in their CFLAGS.
> 
> Just because some flags have "counter"-flags by accident,
> this does not hold for all flags. It is more reasonable to have
> other means that the flags are not modified in the first place.

I can't think of any flags that don't have a corresponding counter flag,
other than -m flags.  At least, all -f and -W flags have opposite -fno and
-Wno versions, even if they're not explicitly documented.

> In fact, when I first introduced adding of CFLAGS, there were
> lot of complaints that this is evil and must not be done.
> I can understand this point of view (even if I know that
> certain CFLAGS should be used with the code and I would also
> prefer to have them to find possibly hidden bugs), so we
> compromised by having an option:
> With this option everybody could live well, since users with
> special settings will not run into trouble because undesired
> flags are added, and other users could just select the USE flag
> and have the benefits of appropriately optimized code.
> Up to now, that is, when we have this IMHO needless discussion
> that an option should not be an option.

If you as upstream have written your code in a way that it benefits from
certain flags (like -ffast-math, -fstrict-aliasing, -fvisibility-hidden,
etc.) then I think enabling those flags by default is the right thing to do.
There are many packages in the tree that do this, so if people are
complaining about it then it's their problem, not yours. ;)

> I hope that this answers also the question of
> Alec Warner <antarus@gentoo.org>:
> 
> : I am confused.  If you want the users to use a default set of CFLAGS
> : you should set this in your build system (autotools, cmake, whatever).
> : [...]
> : I believe the above link seems to describe what you are looking to do
> : using autotools.
> 
> Technically, I have no problem to force in configure.ac that certain
> CFLAGS are used (unless somebody patches the configure.ac, of course).
> The problem is that it is not good to force this if the user disagrees
> (or maybe even unless he explicitly agrees), i.e. it should be an
> option which the user really has. (If this option should only be
> documented in some INSTALL text or in the ./configure output,
> most users do not really have this option, because they would not
> even know about it.)

Maybe the best option in this case really is to use "custom-cflags".  This
gives the user the option of explicitly opting out of your recommended
configuration, while the majority would build the package to your
specifications.  I think this would make everyone happy (?).


-- 
fonts, gcc-porting,                                   and it's all by design
toolchain, wxwidgets                        to keep us from losing our minds
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 896 bytes --]

On Friday, July 02, 2010 16:39:57 Ryan Hill wrote:
> On Fri, 2 Jul 2010 15:29:44 +0200 (CEST) Vaeth wrote:
> > Ryan Hill wrote:
> > > If your build system sets -ffast-math or -fstrict-aliasing
> > > then the user can disable this by setting -fno-fast-math
> > > or -fno-strict-aliasing in their CFLAGS.
> > 
> > Just because some flags have "counter"-flags by accident,
> > this does not hold for all flags. It is more reasonable to have
> > other means that the flags are not modified in the first place.
> 
> I can't think of any flags that don't have a corresponding counter flag,
> other than -m flags.  At least, all -f and -W flags have opposite -fno and
> -Wno versions, even if they're not explicitly documented.

and this isnt "by accident", this is in the fundamental design of gcc argument 
processing.  the only -f/-W flags that lack this are rare exceptions.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]