Jeremy Olexa | 1 Jul 2010 01:25
Picon
Favicon
Gravatar

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

On Wed, 30 Jun 2010 17:09:00 +0200, "Diego E. 'Flameeyes'" Pettenò
<flameeyes <at> 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

Mike Frysinger | 1 Jul 2010 01:03
Picon
Favicon
Gravatar

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

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
Ryan Hill | 1 Jul 2010 07:21
Picon
Favicon
Gravatar

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

On Wed, 30 Jun 2010 23:25:32 +0000
Jeremy Olexa <darkside <at> 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
 <at>  gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
Christian Faulhammer | 1 Jul 2010 10:24
Picon
Favicon

Re: dotnet herd is "empty"

Hi,

Christopher Swift <christopher.swift <at> linux.com>:
> If possible I'd like to contribute to this herd,  I have little ebuild
> experience but I am a willing learner with a keen interest in
> Mono/dotNET technologies.  I am not (yet) a Gentoo developer nor have
> I lots of experience with ebuilds however I have taken an interest in
> writing them lately having read as much documentation as I could find.

 As a general example to learn more about ebuild writing: Use the
Sunrise Overlay where all your contributions get reviewed.

V-Li

--

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>
Vaeth | 1 Jul 2010 14:53
Picon
Favicon
Gravatar

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

(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 <at> 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).
(Continue reading)

Mike Frysinger | 1 Jul 2010 20:40
Picon
Favicon
Gravatar

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

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
Ryan Hill | 1 Jul 2010 22:00
Picon
Favicon
Gravatar

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

On Thu, 1 Jul 2010 14:53:19 +0200 (CEST)
Vaeth <vaeth <at> 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 <at> 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,
(Continue reading)

Nikos Chantziaras | 1 Jul 2010 22:04
Picon
Favicon

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

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.

Alec Warner | 1 Jul 2010 22:21
Picon
Favicon

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

On Thu, Jul 1, 2010 at 1:04 PM, Nikos Chantziaras <realnc <at> 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.
>
>
>

Vaeth | 1 Jul 2010 23:44
Picon
Favicon
Gravatar

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

Ryan Hill <dirtyepic <at> 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
(Continue reading)


Gmane