| View previous topic :: View next topic |
| Author |
Message |
nil
n00b
Joined: 02 Mar 2003
Posts: 16
Location: california, usa
|
 Posted: Wed Mar 05, 2003 10:29 am Post subject: package by package compiler flags? |
 |
|
I'm looking for
1) a way to provide compiler options by package.
-- customized optimizations (d'uh)
-- setting 586 processor flags for packages that use a cmov to compensate for the VIA EDEN CPU's lack of just that capability while retaining 686 optimizations for all other packages
2) a way to merge simple tweaks into a stock ebuild.
-- customizing compile time flags
3) a way of post-processing emerge logs package by package as they are coming in.
-- tailing errors to another console
(1&2 probably are the same)
e.g. _before and _after processing 'scripts'.
i'm looking for the portage system to look into my local ebuild tree so that when it finds specially named files in the package path it would integrate their content into it's flow.
a key reason for wanting a path to integrating my ideas with whatever is most recent and best and stable from the tree is just that.
right now i believe i have to mask builds for which i'm providing changes -- because if i don't they get blown away when the next version gets merged. what a drag to have to remember stuff and to have to supervise the machine on top of it.
perhaps i'm still not getting that this 'soft-merge' already exists in one form or the other, if it does, please tell me! --- if it doesn't .. let me know who or how to suggest this for consideration as a feature.
hmm... as a super super value add for the most amazing and ambitious software generator i've ever had the pleasure of using! yeah, i mean Gentoo by that 
so c'mon folks, tell me you at least understand what the heck i'm trying to do here!
--
http://www.googlism.com/index.htm?ism=nil&type=1
nil is okay unless the documentation for a method states otherwise
nil is designed to degrease and deoxidize and produce a thin protective coating film on the treated metal surface
nil is returned and an error flag is printed
--
_________________
yesterday is just a story |
|
| Back to top |
|
 |
rac
Bodhisattva
Joined: 30 May 2002
Posts: 6553
Location: Japanifornia
|
| Posted: Wed Mar 05, 2003 7:58 pm Post subject: Re: package by package compiler flags? |
|
|
| nil wrote: | | 1) a way to provide compiler options by package. |
Sticky variables are an active area of Portage development, and will provide this functionality.
| Quote: | 3) a way of post-processing emerge logs package by package as they are coming in.
-- tailing errors to another console |
See /var/log/emerge.log.
| Quote: | | i'm looking for the portage system to look into my local ebuild tree so that when it finds specially named files in the package path it would integrate their content into it's flow. |
I think you are describing the PORTDIR_OVERLAY feature.
_________________
For every higher wall, there is a taller ladder |
|
| Back to top |
|
|
axxackall
l33t
Joined: 06 Nov 2002
Posts: 651
Location: Toronto, Ontario, 3rd Rock From Sun
|
| Posted: Wed Mar 05, 2003 8:24 pm Post subject: Re: package by package compiler flags? |
|
|
| rac wrote: | | nil wrote: | | 1) a way to provide compiler options by package. |
Sticky variables are an active area of Portage development, and will provide this functionality. |
Great, where can we read about it?
| rac wrote: | | Quote: | | 3) a way of post-processing emerge logs package by package as they are coming in. -- tailing errors to another console |
See /var/log/emerge.log. |
I've included the following line (the second one in the code bellow) into /usr/sbin/emerge.sh and now I've got emails with the progress report:
| Code: |
$0 $* 2>&1 | tee -a "${PORT_LOGDIR}/${LOG_COUNTER}-${PF}.log"
cat ${PORT_LOGDIR}/${LOG_COUNTER}-${PF}.log |mail my@email.address -s "[emerge-${LOG_COUNTER}] ${PF} ($*)" |
You can send it to another text filter, rather than to email, but then you may have a problem with ebuild, if the text filter can work too long or return the error. So, send it by email to the address with procmail or another mail filtering program and it will be processed asyncronously. |
|
| Back to top |
|
|
nil
n00b
Joined: 02 Mar 2003
Posts: 16
Location: california, usa
|
| Posted: Fri Mar 07, 2003 11:37 am Post subject: Re: package by package compiler flags? |
|
|
Thank you both.
| axxackall wrote: |
| Code: |
$0 $* 2>&1 | tee -a "${PORT_LOGDIR}/${LOG_COUNTER}-${PF}.log"
cat ${PORT_LOGDIR}/${LOG_COUNTER}-${PF}.log |mail my@email.address -s "[emerge-${LOG_COUNTER}] ${PF} ($*)" |
You can send it to another text filter, rather than to email, but then you may have a problem with ebuild, if the text filter can work too long or return the error. So, send it by email to the address with procmail or another mail filtering program and it will be processed asyncronously. |
ok. I think you're on to 'the big answer' here. if you threw that into the emerge.sh script to get an 'after compile effect' i might be able to adapt it to get a 'before compile effect' in the same manner.
see, then we could have it look into the overlay tree to pick out a file to patch the ebuild that is stored in the normal tree.
i think the ability/idea to patch an ebuild rather than having to rewrite it is simpler and more profound then the whole discussion on sticky compiler options.. if you can patch the ebuild then you can do whatever you damn please to those flags as well as having the ability to make changes in compile time flags, yes?
no? yea? does this sound right?
_________________
yesterday is just a story |
|
| Back to top |
|
|
axxackall
l33t
Joined: 06 Nov 2002
Posts: 651
Location: Toronto, Ontario, 3rd Rock From Sun
|
| Posted: Fri Mar 07, 2003 2:44 pm Post subject: Re: package by package compiler flags? |
|
|
| nil wrote: | | axxackall wrote: | | Code: |
$0 $* 2>&1 | tee -a "${PORT_LOGDIR}/${LOG_COUNTER}-${PF}.log"
cat ${PORT_LOGDIR}/${LOG_COUNTER}-${PF}.log |mail my@email.address -s "[emerge-${LOG_COUNTER}] ${PF} ($*)" |
You can send it to another text filter, rather than to email, but then you may have a problem with ebuild, if the text filter can work too long or return the error. So, send it by email to the address with procmail or another mail filtering program and it will be processed asyncronously. |
ok. I think you're on to 'the big answer' here. if you threw that into the emerge.sh script to get an 'after compile effect' i might be able to adapt it to get a 'before compile effect' in the same manner.... |
This code as it is now sends the log file accamulatevely after setup, unpack, compile, install, preinst, postinst - after EVERY stage of ebuild.
| nil wrote: | | ... see, then we could have it look into the overlay tree to pick out a file to patch the ebuild that is stored in the normal tree. |
How is the logging related to ebuild customization? BTW, I don't like idea of patching ebuild. It's much better to include per-package eclasses somewhere from the overlay area.
| nil wrote: | | i think the ability/idea to patch an ebuild rather than having to rewrite it is simpler and more profound then the whole discussion on sticky compiler options.. if you can patch the ebuild then you can do whatever you damn please to those flags as well as having the ability to make changes in compile time flags, yes? |
You are in your motivation. But I disagree with methods. Again, no need to patch anything, as patching relies on the syntax of ebuilds, which can be changed from rsync to rsync (i.e. the sentence order can be changed). It's much better to inherit eclasses. Today we inherit them by the explicit statement if such presented in the official ebuild. Why not inherit implicitly from per-package overlay area? It's a one line of code somewhere in ebuild.sh (have to see myself once I'll have free time for that). |
|
| Back to top |
|
|
nil
n00b
Joined: 02 Mar 2003
Posts: 16
Location: california, usa
|
| Posted: Fri Mar 07, 2003 10:43 pm Post subject: Re: package by package compiler flags? |
|
|
| axxackall wrote: |
You are in your motivation. But I disagree with methods. Again, no need to patch anything, as patching relies on the syntax of ebuilds, which can be changed from rsync to rsync (i.e. the sentence order can be changed). It's much better to inherit eclasses. Today we inherit them by the explicit statement if such presented in the official ebuild. Why not inherit implicitly from per-package overlay area? It's a one line of code somewhere in ebuild.sh (have to see myself once I'll have free time for that). |
Why not?
First let me say that you're totally right on the money about patching vs inheriting.
The quandry i see is when you look at getting the next 5 updates to the package you've just spent time deriving from.
afaiui you need to tune/name/bind your overrides to an arbitrary version. and if that changes 'cause you updated.. you're likely sool. your inheritance will have been blown and you need to manually tweak and map and mask to get your 'delta' back into the ebuild.. one way or the other.
yes?
so, my notion of version independent patches applied to whatever is the latest ebuild on file takes that away.
hey and if the version independent patch fails cause some underling standard changed then so be it. then there's an 'EXCEPTION', i'd want the patch process to crash/stop/let me know i have work to do.
so looking at 5 generations of updated ebuilds for 10 tweaked packages I'm faced with LOTS AND LOTS of administrative yuck if i have to register my ideas about what i want to be different on the level of the ebuild version.
if i can 'patch version independently' then maybe out of 5 generations of updated ebuilds for 10 tweaked packages I wind up with one or two or three administrative events instead of 50.
I can handle 1.2.3. tweaks and know i'll be good. but the idea of having to be prepared to tweak my shit cause somebody wants to bump a version without really making any changes is abhorrent i dont want to be this dependent on everybody. i dont want minor ebuild tweaks to cause me any work!
you've looked through the changelogs that come with the ebuilds, yes? the one's i've looked at seemed to indicate that there would have been a lot of work for me to keep versions and stuff lined up -- while the substance of what i would have wanted to affect was unchanged.
inheritance is a good thing.
version independent inheritance that blows out if there's a problem.. now you have something.
i believe that version indep inhe/or patches would also make easy work out of persistent compiler options. at least you would have an easy place to store your compiler option tweaks. just put them in the overlay path.
alright... so much for that. its hard work to setup something that lets you be lazy like i'm envisioning
perhaps this could be an option that's sold on the premise of simply providing a robust solution to the 'customized compiler options' thing now being discussed;
you just make your _tweaks.sh in the overlay path and in it you emit a warning message in case the version you're now applying our options to has changed from the version you've tested your cflags with. you get to pick what packages you want to have that happen with and you get to control the severity or your response lib by lib.
from a design pov this would be preferable than overloading the current tree management system with another system serving orthogonal needs. In fact, the danger of implementing persistent compiler options through a central variable repository is that you cripple the capabilities of this now extremely well focused and powerful system.
hey, even if i get back a no, such as in the onion headline 'child's prayer to god answered no', this need to be lazy, err, live under the LAW, e.g. Least Amount of Work, is pretty real for me and it would sure leave me with a nasty feeling about my system if i was locked in to having to hack something as essential .. rather than finding a way to get this need met without vigilance on my part.
remember.. if patch can't do its work then this version independent overlay thing would fail. but like i said, from looking at the changelogs i think this would only happen very infrequently.
la la la la a.
sorry this got so long, but i'm waaay to lazy to not want to understand how to be even lazier. ..lazy is good. gives me more time to learn other stuff
I'm glad you wrote back! Thank you.
_________________
yesterday is just a story |
|
| 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
|
|
Portage & Programming
