On Thu, 1 Jul 2010 23:44:17 +0200 (CEST) Vaeth <va...@mathematik.uni-wuerzburg.de> wrote:
> Ryan Hill <dirtye...@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
signature.asc
Description: PGP signature
