Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Vaeth <vaeth@...>
Subject: Re: [gentoo-dev-announce] debug USE flag misuse
Date: Thu, 1 Jul 2010 14:53:19 +0200 (CEST)
(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@g.o> 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
Replies:
Re: [gentoo-dev-announce] debug USE flag misuse
-- Vaeth
Re: [gentoo-dev-announce] debug USE flag misuse
-- Ryan Hill
Re: Re: [gentoo-dev-announce] debug USE flag misuse
-- Mike Frysinger
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: [gentoo-dev-announce] debug USE flag misuse
Next by thread:
Re: Re: [gentoo-dev-announce] debug USE flag misuse
Previous by date:
Re: dotnet herd is "empty"
Next by date:
Re: Re: [gentoo-dev-announce] debug USE flag misuse


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.