View previous topic :: View next topic |
Author |
Message |
Donman Tux's lil' helper
Joined: 05 Sep 2005 Posts: 117
|
Posted: Thu Jun 15, 2006 3:41 am Post subject: |
|
|
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 |
|
|
Dralnu Veteran
Joined: 24 May 2006 Posts: 1919
|
Posted: Sun Aug 27, 2006 11:00 am Post subject: |
|
|
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 |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6749
|
Posted: Sun Aug 27, 2006 7:33 pm Post subject: |
|
|
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 |
|
|
Dralnu Veteran
Joined: 24 May 2006 Posts: 1919
|
Posted: Sun Aug 27, 2006 9:31 pm Post subject: |
|
|
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 |
|
|
Lloeki Guru
Joined: 14 Jun 2006 Posts: 437 Location: France
|
Posted: Tue Sep 19, 2006 6:50 pm Post subject: |
|
|
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 |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6749
|
Posted: Tue Sep 19, 2006 11:59 pm Post subject: |
|
|
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 |
|
|
Lloeki Guru
Joined: 14 Jun 2006 Posts: 437 Location: France
|
Posted: Wed Sep 20, 2006 11:01 am Post subject: |
|
|
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 |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6749
|
Posted: Wed Sep 20, 2006 12:49 pm Post subject: |
|
|
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 |
|
|
Dralnu Veteran
Joined: 24 May 2006 Posts: 1919
|
Posted: Wed Sep 20, 2006 6:09 pm Post subject: |
|
|
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 |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6749
|
Posted: Thu Sep 21, 2006 1:57 pm Post subject: |
|
|
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 |
|
|
Dralnu Veteran
Joined: 24 May 2006 Posts: 1919
|
Posted: Fri Sep 22, 2006 1:45 am Post subject: |
|
|
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 |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Tue Oct 03, 2006 3:36 pm Post subject: |
|
|
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 |
|
|
Dralnu Veteran
Joined: 24 May 2006 Posts: 1919
|
Posted: Wed Oct 04, 2006 12:00 am Post subject: |
|
|
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 |
|
|
turtles Veteran
Joined: 31 Dec 2004 Posts: 1666
|
Posted: Sat Sep 01, 2007 11:14 pm Post subject: |
|
|
Is anyone still using a /etc/portage/env dir? IF so what packages are you optimising?
cheers |
|
Back to top |
|
|
fb l33t
Joined: 08 Dec 2003 Posts: 636 Location: New Zealand
|
Posted: Sun Sep 02, 2007 7:52 am Post subject: |
|
|
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 |
|
|
|
|
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
|
|