/etc/portage/package.c{,xx}flags features - v1.0_rc1

[Donman]

rojanu wrote:

OK now I get
Quote:
This bashrc does not know anything about /usr/lib/portage/bin/misc-functions.sh
any ideas!

I get that same message spit out at me, but it seems that it doesnt affect the script. I'm using smoked's script (great script by the way, thank you all for this) and when I set a packages LDFLAGS in package.ldflags, then type "DEBUG=1 ebuild /usr/portage/<path>/<to>/<ebuild> clean" it overrides the LDFLAGS in make.conf fine. I say just ignore that message, since everything still works. Hope this helps!

[Dralnu]

This looks great. Before I start to mess with things (currently I am chroot-less for a test enviroment), has anything with this been upgraded since the original scripts, or is it kind of a dead project?

[mv]

This looks great. Before I start to mess with things (currently I am chroot-less for a test enviroment), has anything with this been upgraded since the original scripts, or is it kind of a dead project?

There are a lot of scripts like this. You migh also e.g. want to have a look at portage-bashrc from
http://www.mathematik.uni-wuerzburg.de/ ... index.html

[Dralnu]

I'll look into that in a bit when I get some time. Thanks

[Lloeki]

hmm, what about going more general and have /etc/portage/package.foo_bar set (with union and precedence) variable FOO_BAR for each package listed inside?

[mv]

hmm, what about going more general and have /etc/portage/package.foo_bar set (with union and precedence) variable FOO_BAR for each package listed inside?

What do you mean: "More general" (than ...)
Having all CFLAGS (CXXFLAGS/LDFLAGS/...) for the packages listed separately is not very convenient: For most packages you will want the same CFLAGS, and it is much more convenient if you can modify these "defaults" in some central place. Only for certain packages you might want to exclude some flags from the defaults or, for simplicity, all "optimization" use flags, or you might want to add certain flags. However, you will usually no want to change other flags like -march=... or -pipe. Only for very exceptional packages you might want a completely different set of CFLAGS. So I think an approach which allows to add/remove CFLAGS to "default" flags, and also a brief way to remove all "critical" optimization useflags from the "defaults" is the most convenient one - and if you like, you can still remove all flags and set your own for a certain package (although I don't know a reason why you ever would like to remove "-march=...").

[Lloeki]

I mean, like you don't list all use flags for each package.
say you have in make.conf

Code: Select all

CFLAGS=-O2 -march=pentium-m -pipe

you could have in packge.cflags

Code: Select all

foo-bar/baz-gazonk -O3 -msse -mfp-math=sse
arfle-barfle/gloop-quux -O -mtune=pentium-m

which would result at execution into emerge-time CFLAGS for foo-bar/baz-gazonk:

Code: Select all

-O3 -msse -mfp-math=sse -march=pentium-m -pipe

and for arfle-barfle/gloop-quux

Code: Select all

-O -mtune=pentium-m -pipe

this would also work for package.cxxflags, package.video_cards, package.linguas, package.makeopts.... that's what I mean for general.

indeed this would require a fair amount of coding, but when I started to use gentoo, that's what I expected for the /etc/portage dir.

[mv]

Code: Select all

-O3 -msse -mfp-math=sse -march=pentium-m -pipe

and for arfle-barfle/gloop-quux

Code: Select all

-O -mtune=pentium-m -pipe

So you suggest that only useflags can be added and that adding of certain useflags "automagically" omits other use flags (e.g. -O3 or -O omits a previous -O2, -mtune omits a previous -march (BTW why should this be reasonable))? However, such an "automagic" might go wrong, e.g. it might make sense to specify both "-O2 -O3" because e.g. a certain ebuild might filter -O3 but not -O2 and perhaps a later version of the ebuild might have no need to filter -O3. Similar questions arise for optimization flags contained in an -O?. And what do you want to do if you e.g. want to omit the -pipe for some package due to memory problems?

Did you really have a look at the above suggested portage-bashrc from http://www.mathematik.uni-wuerzburg.de/ ... index.html? With this you can do all what you suggested (except for this "automagic" behavior: You have to specify explicitly which flags you want to omit). In addition, it allows you to add/not add additional "optimiziation" OPTCFLAGS/OPTCXXFLAGS/... which you specify explicitly in /etc/make.conf. The main difference to your suggestion is that not each *flags is stored in a separate file which, however, is also reasonable, since usually you will want to add/not add certain flags to each of the variables CFLAGS/CXXFLAGS/FFLAGS simultaneously, and also the LDFLAGS should sometimes be added to the other flags - so it is not so natural to store each in a separate file (of course adding/removal of a flag only to some of this variables is also possible with this script if you need this). So, in a sense this portage-bashrc is much more general than your suggestion (that's why I did not understand why you said "more general").

[Dralnu]

ebuilds filtering out optimazations is a problem. Here is a suggestion:

When a new package is downloaded and going to be installed, before running make, transfer the entries from the ebuild to the package.c(xx)flags file under such as:

foo-et/bar +* -march=pentium -O2 -pipe #ebuild optimazations. Modify at own risk

where the + translates to "Don't use the following flags", while - tells it to use them. The comment following would just make things easier, along with possibly including a bug number to report to if someone changed the settings, and found out that, say, -O3 worked, then they could then possible do this:

foo-et/bar +* -march=pentium -O2 -pipe #-O3 works according to <bug #> #ebuild optimazations. Modify at own risk.

to keep the "safe" settings, but to let it be known that if they want to, it can b optimzed further. This would probably be done best if using a set of files (package.c(xx)flags/user.c(xx)flags && package.c(xx)flags/<safe/default>.c(xx)flags), one for the user, one for the ebuild-specific, safe settings, with the safe settings overriding the users, unless otherwise stated in make.conf.

[mv]

transfer the entries from the ebuild to the package.c(xx)flags file

This cannot work for all packages, because in general there is not the CFLAGS entry of the .ebuild. An ebuild can do much more than filtering flags (and many do this): It can add flags in dependence of the architecture or of certain other CFLAGS or USE-flags or even only modify the CFLAGS for parts of the package (e.g. an ideal .ebuild would use -fPIC precisely for the libraries). So I cannot understand why you propagate "static" files for (potentially and in some cases actually) "highly nonstatic" .ebuilds.

It would be simpler to require that .ebuilds be written "perfect": A perfect .ebuild would filter all non-working flags but also only those. So if all .ebuilds were written perfectly, there would be no need for any additional file at all overriding CFLAGS...

[Dralnu]

It would be simpler to require that .ebuilds be written "perfect": A perfect .ebuild would filter all non-working flags but also only those. So if all .ebuilds were written perfectly, there would be no need for any additional file at all overriding CFLAGS...

Simpler, yes, but when you figure on how libs and programs run together, sometimes with one setup it will work, and others it won't for some weird reason.

Its an admining nightmare to make sure EVERY unusable CFLAG is filtered.

[steveL]

This looks great. Before I start to mess with things (currently I am chroot-less for a test enviroment), has anything with this been upgraded since the original scripts, or is it kind of a dead project?

According to [topic=488223]this topic[/topic] (which has been set to a dup of this one) we can override any environmental vars (CFLAGS, LDFLAGS etc) by using /etc/portage/env/ directory. We need the specific category under that dir, with a file of the same name as the package.

Assuming you want to set CFLAGS="blah blih blouh -full-speed-on" then you can do this

Code: Select all

mkdir /etc/portage/env/category 
echo 'CFLAGS="blah blih blouh -full-speed-on"' >> /etc/portage/env/category/packagename

Note this is not restrictive to CFLAGS.

for example:

Code: Select all

for pkg in {dev-lang/tk,dev-lang/tcl,net-im/amsn} ; do mkdir /etc/portage/env/${pkg%/*} ; echo "EXTRA_ECONF="--enable-xft"" >> /etc/portage/env/$pkg ; done

I'm guessing the version, eg of CLFAGS, overrides the existing value, and does not combine with it.

Still it's great to know we can do this (eg for LDFLAGS with xorg.)

Edit:[topic=489416]This topic[/topic] mentions:

Using (pkgname) will generally override /etc/make.conf
If you also have (pkgname)-(version) will override both (pkgname) and /etc/make.conf

This is just the behavior I'd like to see.

[Dralnu]

This looks great. Before I start to mess with things (currently I am chroot-less for a test enviroment), has anything with this been upgraded since the original scripts, or is it kind of a dead project?

According to [topic=488223]this topic[/topic] (which has been set to a dup of this one) we can override any environmental vars (CFLAGS, LDFLAGS etc) by using /etc/portage/env/ directory. We need the specific category under that dir, with a file of the same name as the package.

Assuming you want to set CFLAGS="blah blih blouh -full-speed-on" then you can do this

Code: Select all

mkdir /etc/portage/env/category 
echo 'CFLAGS="blah blih blouh -full-speed-on"' >> /etc/portage/env/category/packagename

Note this is not restrictive to CFLAGS.

for example:

Code: Select all

for pkg in {dev-lang/tk,dev-lang/tcl,net-im/amsn} ; do mkdir /etc/portage/env/${pkg%/*} ; echo "EXTRA_ECONF="--enable-xft"" >> /etc/portage/env/$pkg ; done

I'm guessing the version, eg of CLFAGS, overrides the existing value, and does not combine with it.

Still it's great to know we can do this (eg for LDFLAGS with xorg.)

Edit:[topic=489416]This topic[/topic] mentions:

Using (pkgname) will generally override /etc/make.conf
If you also have (pkgname)-(version) will override both (pkgname) and /etc/make.conf

This is just the behavior I'd like to see.

Hmm, interesting. I'll look into that soon and see what I can mange here

[turtles]

Is anyone still using a /etc/portage/env dir? IF so what packages are you optimising?
cheers

[fb]

Is anyone still using a /etc/portage/env dir? IF so what packages are you optimising?
cheers

In my case on ppc it is not a question of optimization. OpenOffice.org does not build
with my regular CFLAGS so I have a special entry with working CFLAGS for it.
Also I use -Wl,--as-needed and some package are not ready for this LD_FLAGS, sometimes a ~arch
version is ok, sometimes there is a patch in bugzilla but I am too lazy to integrate it in my overlay.
Sometimes it just doesn't seem to work.
Please note that if you use -Wl,--as-needed the failure of building a package may come from one of
the libraries you link to. Everything is explained here
and the bug is [bug=129413]here[/bug].