1 |
Disclaimer: |
2 |
Don't mind that it starts off ranting. I actually like some |
3 |
of the implementation ideas presented. Any discussion on my |
4 |
dillusions of grandjeur or my inability to spell will get |
5 |
you smited in a very not nice way. |
6 |
|
7 |
> 1) Possibility to change ENV during building some packages. |
8 |
|
9 |
I certainly hope you realize the depths to which people go to |
10 |
make your life miserable when attempting to do support. |
11 |
|
12 |
Something like this will happen: |
13 |
source /etc/profile |
14 |
|
15 |
Which does something great to the users console, but will |
16 |
probably have destructive results otherwise. Bugs will now |
17 |
require you to review not only the settings that portage |
18 |
reports, but you will also have to check every related script |
19 |
that the user decides to make part of the build process. |
20 |
Unless we ignore anyone using these features. Would be funny |
21 |
in that bated, ironic-reversal kinda way. |
22 |
|
23 |
If they decide to alias something, it will have an affect |
24 |
IN THE BUILD. Portage makes a lot of effort to prevent |
25 |
things like this right now. unsets + unalias, are a quick |
26 |
example. |
27 |
|
28 |
> 2) it should be automatic, no more definition of environment variables |
29 |
> and manual emerging packages. No more spaming /etc/make.conf with some |
30 |
> environment variables which correspond only to one package (RXVT_TERM, |
31 |
> for example) |
32 |
|
33 |
The idea is that it takes effort. If it's not trivial, you have to |
34 |
LEARN to make it work. Having super-easy things is great, but not |
35 |
when it happens to make FIXING it super complicated, developers lose. |
36 |
|
37 |
The single package variables are mostly new to me, thus I have no |
38 |
opinion on them. |
39 |
|
40 |
> 3) Solution must be flexible and allow us to have not only |
41 |
> "per-package" variables set, but also define some general sets for |
42 |
> inclusion. For example if we want to build soft1,soft2,ans soft3 with |
43 |
> IFC, we really don't want to have 3 copies of something like: |
44 |
> F77=ifc |
45 |
> FC=ifc |
46 |
> F90=ifc |
47 |
> FFLAGS="-xN -ip" |
48 |
> Moreover, when we will decide to change CPU, we will not need to edit 3 |
49 |
> files and change -xN to -xP. We want to do it once. :) |
50 |
|
51 |
Some of this might be nice. If you're going to make this kind of |
52 |
effort, why not integrate it into the ebuild? |
53 |
|
54 |
> 4) BTW, in such case it also not bad to have option to include something |
55 |
> like |
56 |
> USE="ifc" |
57 |
> into this environment, and it should be parsed in proper way. I hope |
58 |
> that this is clear. If we want to build something with IFC and set |
59 |
> proper variables, we really don't want to go and edit one more file |
60 |
> (/etc/portage/package.use). And we don't want to edit also two files, |
61 |
> when we will figure out that we like coming gfortran :) |
62 |
|
63 |
Absolutely not. This violates portage's dep calculations and is |
64 |
completely wrong. Please do not change any variables that are |
65 |
READONLY inside of ebuild.sh after the depend phase. |
66 |
|
67 |
> So, lets define our problem in more details: |
68 |
> 1) Assume that default configuration of my system is |
69 |
> GCC 3.4.1 |
70 |
> CFLAGS="-O2 -pipe" in /etc/make.conf |
71 |
> LINGUAS="ru" in /etc/make.conf |
72 |
> there is no defined ifc and icc USE flags in /etc/make.conf |
73 |
> |
74 |
> 2) I have set of packages, that require something "extra" |
75 |
> lam-mpi : want to compile with ICC, IFC |
76 |
> blas-reference : want to compile with g77 and high optimization |
77 |
> lapack-reference : want to compile with g77 and high optimization |
78 |
> blas-atlas: want to compile with IFC, ICC |
79 |
> lapack-atlas: want to compile with IFC, ICC |
80 |
> xine-lib : want to compile with low-optimization for GCC |
81 |
> open office : want to compile with LANGUAGE="RUSS" and GCC 3.3.4 and |
82 |
> low-optimization |
83 |
> kde-i18n : want to have with LINGUAS="fr" and GCC 3.3.4 |
84 |
> rxvt : want to compile with RXVT_TERM=xterm |
85 |
> octave : want to build with high-optimization for GCC |
86 |
> |
87 |
> |
88 |
> so, what I see? |
89 |
> Something like: |
90 |
> |
91 |
> #cat /etc/portage/package.env |
92 |
> lam-mpi: icc ifc |
93 |
> blas-reference: g77high.env |
94 |
> lapack-reference: g77high.env |
95 |
> blas-atlas: ifc.env icc.env |
96 |
> lapack-atlas: ifc.env icc.env |
97 |
> xine-lib: GCC_lowopt.env |
98 |
> openoffice: language_ru.env GCC_334.env GCC_lowopt.env |
99 |
> kde-i18n: linguas_fr.env |
100 |
> rxvt: rxvt.env |
101 |
> octave: GCC_highopt.env |
102 |
> |
103 |
> |
104 |
> #ls /etc/portage/env |
105 |
> ifc.env |
106 |
> ifc.env |
107 |
> GCC_highopt.env |
108 |
> GCC_lowopt.env |
109 |
> rxvt.env |
110 |
> linguas_fr.env |
111 |
> language_ru.env |
112 |
> GCC_334.env |
113 |
> g77high.env |
114 |
> |
115 |
> and |
116 |
> #cat /etc/portage/env/icc.env |
117 |
> CC=icc |
118 |
> CXX=icc |
119 |
> CFLAGS="-O2 -xN -noalign" |
120 |
> CXXFLAGS=$CFLAGS |
121 |
> USE="icc" |
122 |
> |
123 |
> #cat /etc/portage/env/GCC_highopt.env |
124 |
> CFLAGS="-O3 -ffast-math -funroll-all-loops -fmove-all-movables" |
125 |
> |
126 |
> #cat /etc/portage/env/GCC_lowopt.env |
127 |
> CFLAGS="-O1" |
128 |
> |
129 |
> #cat /etc/portage/env/GCC_334.env |
130 |
> CC=/usr/i686-pc-linux-gnu/gcc-bin/3.3/gcc |
131 |
> g77=/usr/i686-pc-linux-gnu/gcc-bin/3.3/g77 |
132 |
> |
133 |
> And rest it similar. |
134 |
> |
135 |
> Of course, it could be not so bad, to have option, to include name of |
136 |
> file with ENV, or just env, to not produce tens of files with one |
137 |
> variable, like RXVT_TERM="xterm"... There is seems to be two solutions: |
138 |
> 1) just have second file with definitions, where not filenames, but |
139 |
> defined variables. |
140 |
> 2) change syntax of /etc/portage/package.env in such way, that allow to |
141 |
> include both kind of records, filename and strict definition inline. |
142 |
> something like |
143 |
> openoffice: GCC_334.env GCC_lowopt.env -- LANGUAGE="RUSS" |
144 |
> |
145 |
> |
146 |
> For the moment both solutions looks ugly for me. At least I can't |
147 |
> imaging simple and easy-to-understand syntax for package.env, which will |
148 |
> look nice and will parce without problems. |
149 |
> |
150 |
> What do you think about? |
151 |
|
152 |
Some of the ideas actually look trackable, which I happen |
153 |
to like. Inline definitions of variables, I am not |
154 |
particularly fond of. |
155 |
|
156 |
If portage has a way to accurately track these files and |
157 |
there is a way to avoid arbitary inclusion, then it might |
158 |
be a lot more feasable. |
159 |
|
160 |
Providing code would be nice too. An interface to track and |
161 |
an interface whereby portage controls the inclusions. |
162 |
|
163 |
I'm very much against out-of-file references. |
164 |
|
165 |
Eh. That is all I have to say. |
166 |
I'm going to go home and take a nap now. |
167 |
|
168 |
--NJ |