Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
/etc/portage/package.c{,xx}flags features - v1.0_rc1
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
Donman
Tux's lil' helper
Tux's lil' helper


Joined: 05 Sep 2005
Posts: 117

PostPosted: Thu Jun 15, 2006 3:41 am    Post subject: Reply with quote

rojanu wrote:
Quote:
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!
Back to top
View user's profile Send private message
Dralnu
Veteran
Veteran


Joined: 24 May 2006
Posts: 1919

PostPosted: Sun Aug 27, 2006 11:00 am    Post subject: Reply with quote

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?
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sun Aug 27, 2006 7:33 pm    Post subject: Reply with quote

Dralnu wrote:
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/~vaeth/gentoo/index.html
Back to top
View user's profile Send private message
Dralnu
Veteran
Veteran


Joined: 24 May 2006
Posts: 1919

PostPosted: Sun Aug 27, 2006 9:31 pm    Post subject: Reply with quote

I'll look into that in a bit when I get some time. Thanks
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.
Back to top
View user's profile Send private message
Lloeki
Guru
Guru


Joined: 14 Jun 2006
Posts: 437
Location: France

PostPosted: Tue Sep 19, 2006 6:50 pm    Post subject: Reply with quote

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?
_________________
Moved to using Arch Linux
Life is meant to be lived, not given up...
HOLY COW I'M TOTALLY GOING SO FAST OH F*** ;)
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Tue Sep 19, 2006 11:59 pm    Post subject: Reply with quote

Lloeki wrote:
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=...").
Back to top
View user's profile Send private message
Lloeki
Guru
Guru


Joined: 14 Jun 2006
Posts: 437
Location: France

PostPosted: Wed Sep 20, 2006 11:01 am    Post subject: Reply with quote

I mean, like you don't list all use flags for each package.
say you have in make.conf
Code:
CFLAGS=-O2 -march=pentium-m -pipe

you could have in packge.cflags
Code:
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:
-O3 -msse -mfp-math=sse -march=pentium-m -pipe

and for arfle-barfle/gloop-quux
Code:
-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.
_________________
Moved to using Arch Linux
Life is meant to be lived, not given up...
HOLY COW I'M TOTALLY GOING SO FAST OH F*** ;)
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Wed Sep 20, 2006 12:49 pm    Post subject: Reply with quote

Lloeki wrote:
Code:
-O3 -msse -mfp-math=sse -march=pentium-m -pipe

and for arfle-barfle/gloop-quux
Code:
-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/~vaeth/gentoo/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").
Back to top
View user's profile Send private message
Dralnu
Veteran
Veteran


Joined: 24 May 2006
Posts: 1919

PostPosted: Wed Sep 20, 2006 6:09 pm    Post subject: Reply with quote

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.
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Thu Sep 21, 2006 1:57 pm    Post subject: Reply with quote

Dralnu wrote:
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...
Back to top
View user's profile Send private message
Dralnu
Veteran
Veteran


Joined: 24 May 2006
Posts: 1919

PostPosted: Fri Sep 22, 2006 1:45 am    Post subject: Reply with quote

mv wrote:
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.
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Tue Oct 03, 2006 3:36 pm    Post subject: Reply with quote

Dralnu wrote:
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 this 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.
truc wrote:
Assuming you want to set CFLAGS="blah blih blouh -full-speed-on" then you can do this
Code:
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:
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:This topic mentions:
depontius wrote:
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.
Back to top
View user's profile Send private message
Dralnu
Veteran
Veteran


Joined: 24 May 2006
Posts: 1919

PostPosted: Wed Oct 04, 2006 12:00 am    Post subject: Reply with quote

steveL wrote:
Dralnu wrote:
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 this 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.
truc wrote:
Assuming you want to set CFLAGS="blah blih blouh -full-speed-on" then you can do this
Code:
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:
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:This topic mentions:
depontius wrote:
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 :)
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.
Back to top
View user's profile Send private message
turtles
Veteran
Veteran


Joined: 31 Dec 2004
Posts: 1646

PostPosted: Sat Sep 01, 2007 11:14 pm    Post subject: Reply with quote

Is anyone still using a /etc/portage/env dir? IF so what packages are you optimising?
cheers
Back to top
View user's profile Send private message
fb
l33t
l33t


Joined: 08 Dec 2003
Posts: 636
Location: New Zealand

PostPosted: Sun Sep 02, 2007 7:52 am    Post subject: Reply with quote

turtles wrote:
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 here.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum