| 1 |
Nicholas Jones wrote: |
| 2 |
>>1) Possibility to change ENV during building some packages. |
| 3 |
> |
| 4 |
> |
| 5 |
> I certainly hope you realize the depths to which people go to |
| 6 |
> make your life miserable when attempting to do support. |
| 7 |
Yes :) There is something |
| 8 |
> The idea is that it takes effort. If it's not trivial, you have to |
| 9 |
> LEARN to make it work. Having super-easy things is great, but not |
| 10 |
> when it happens to make FIXING it super complicated, developers lose. |
| 11 |
Yes, but sollution can be simple...some kind of, probably, limitation |
| 12 |
applied, at first (for example ONLY env variables, nothing more in this |
| 13 |
script, onle A=B syntax). And second, idea to get this environment |
| 14 |
BEFORE something. So, it should be absolutely equal, theoretically, to |
| 15 |
something like this: |
| 16 |
CC="bla-bla-bla" CFLAGS="bla-bla-bla" I_WANT_THAT="bla-bla-bla" emerge |
| 17 |
nice_package |
| 18 |
I thing that is OK, because anyway users can do it now :) |
| 19 |
|
| 20 |
> Some of this might be nice. If you're going to make this kind of |
| 21 |
> effort, why not integrate it into the ebuild? |
| 22 |
If I uderstand right, you mean make copy of 10 ebuilds into local |
| 23 |
overlay and edit them twice a week? When new version of ebuild is |
| 24 |
coming? :) And in the middle have troubles, because fresh version will |
| 25 |
be at first automatically updated with standard ENV and at morning I'll |
| 26 |
reallize that my code don't want to be linked against of library XXX, |
| 27 |
which was compiled at night with g77 instead ifc or lf95 or pgf90 or |
| 28 |
something else ? :) That is boring. I've checked already :) |
| 29 |
|
| 30 |
|
| 31 |
>>4) BTW, in such case it also not bad to have option to include something |
| 32 |
>>like |
| 33 |
>>USE="ifc" |
| 34 |
>>into this environment, and it should be parsed in proper way. I hope |
| 35 |
>>that this is clear. If we want to build something with IFC and set |
| 36 |
>>proper variables, we really don't want to go and edit one more file |
| 37 |
>>(/etc/portage/package.use). And we don't want to edit also two files, |
| 38 |
>>when we will figure out that we like coming gfortran :) |
| 39 |
> |
| 40 |
> |
| 41 |
> Absolutely not. This violates portage's dep calculations and is |
| 42 |
> completely wrong. Please do not change any variables that are |
| 43 |
> READONLY inside of ebuild.sh after the depend phase. |
| 44 |
Again. Idea of this way is to have something equal to |
| 45 |
CC="bla-bla-bla" CFLAGS="bla-bla-bla" I_WANT_THAT="bla-bla-bla" |
| 46 |
USE="I_dont_want_that" emerge nice_package |
| 47 |
This way is OK and works now. Yes, it probably going to be a bit |
| 48 |
complicated and probably you will need to parse it twice...that is |
| 49 |
subject of dicussion. |
| 50 |
|
| 51 |
|
| 52 |
> Some of the ideas actually look trackable, which I happen |
| 53 |
> to like. Inline definitions of variables, I am not |
| 54 |
> particularly fond of. |
| 55 |
> |
| 56 |
> If portage has a way to accurately track these files and |
| 57 |
> there is a way to avoid arbitary inclusion, then it might |
| 58 |
> be a lot more feasable. |
| 59 |
Keep in mind, it was a first iteration :) Not really well designed |
| 60 |
Just wanted to rise discussion. After which idea could take shape of |
| 61 |
brilliant :) |
| 62 |
|
| 63 |
|
| 64 |
> Eh. That is all I have to say. |
| 65 |
> I'm going to go home and take a nap now. |
| 66 |
:) |
| 67 |
|
| 68 |
-- |
| 69 |
Anton Starikov |
| 70 |
|
| 71 |
-- |
| 72 |
gentoo-dev@g.o mailing list |
Archives