1 |
Hi! |
2 |
|
3 |
Recently there was added "ifc" flag to support Intel Fortran Compiler. |
4 |
And few ebuilds already take it into account. But... |
5 |
|
6 |
1) Mainly it corresponds to some scientific libraries and programs. And |
7 |
I guess that not 99% of such users use ifc. What about ones who use |
8 |
Absoft, Lahey Fujitsu, Portland Group and so on? I guess IFC didn't take |
9 |
99% of market yet. Because other companies still alive. :) Moreover, |
10 |
AFAIK a lot of people prefer different compilers because IFC still has |
11 |
some compatibility problems with complicated codes. Which can be |
12 |
compiled without problems with Absoft or Lahey, for example. |
13 |
|
14 |
2) Optimization flags. I've take a short look at some ebuilds which use |
15 |
IFC and ICC flags. Mostly they have hard-encoded into ebuilds |
16 |
optimization flags. Which also doesn't seems to be really brilliant |
17 |
idea. Of course, some of them check IFCFLAGS and ICCFLAGS environment |
18 |
variables...but it is not common, and it is less portable from pint of |
19 |
view of different compilers. |
20 |
|
21 |
OK, partly you can solve such problems with setting some environment |
22 |
variables, like F77 and so on. But...it not looks like a really gentoo |
23 |
solution, it is not really reliable solution (for example blas-atlas |
24 |
will just ignore it, AFIR) and so on. |
25 |
|
26 |
So, probably there is some need to make some kind of redesign of the |
27 |
idea. OK, for C and C++ it is not so important probably, because there |
28 |
is not such big choice and anyway mostly you would prefer GCC, and if |
29 |
you want, support for icc and tiny-cc here already. |
30 |
|
31 |
Situation with Fortran just looks a bit more complicated. And different |
32 |
from C world. |
33 |
|
34 |
So, has it sense to think about implementing some abstract |
35 |
multi-compiler support? at least for Fortran guys. |
36 |
But generally, probably, it could be just let say "minor compiler |
37 |
support", which means, for C and F you still have gcc and g77 (gfortran |
38 |
in future) as a main compiler of the system, but you can also choose |
39 |
some kind of minor compiler. Now it almost work in such way with ICC. |
40 |
ICC behaves just as some kind of minor compiler and some software that |
41 |
can be compiled with ICC will be compiled with icc. |
42 |
|
43 |
This idea "of minor compiler support" could be also interesting for |
44 |
different applications. For example, hypothetic situation: I have SPARC |
45 |
with Solaris. I'm not going to completely change my OS, but, probably, I |
46 |
would like to take advantages of gentoo portage also. And probably I |
47 |
would like to choose second compiler (SUN compiler of course), which |
48 |
will be used for compilation of some stuff that can be compiled with it. |
49 |
And, if software use automake and autoconf, it probably will be compiled |
50 |
without real troubles. |
51 |
|
52 |
It basically looks very interesting and not such hypothetic, because |
53 |
anyway nowadays you fill your Solaris box (or Irix box) with incredible |
54 |
amount of GNU stuff, if you want to have some comfort :) And, I guess, |
55 |
portage can be really, easy adopted to that. OK, it couldn't be in |
56 |
mainstream. But...if, let say, you have 300 Solaris clients and ppl |
57 |
whant to use a really a LOT of different stuff, either you compile |
58 |
program by program by yourself and put in on a servers into shared /usr |
59 |
folder (or whatevere else), or you just force portage think that you |
60 |
have gentoo and portage do you job for you and just go and drink coffe |
61 |
:) Thats real example. |
62 |
|
63 |
|
64 |
Of course, there is two ways to implement this. |
65 |
One - it's just to add more and more USE flags for different compilers. |
66 |
it is some kind of clean way with granted result, if you ebuild support |
67 |
this compiler which you have in USE flags...but... |
68 |
I guess, at least in case of Fortran. ebuild that can be compiled with |
69 |
ANY Fortran compiler wail NEVER check for all these flags, because for |
70 |
such behavior ebuild should be tested with ALL these compilers, reported |
71 |
that it works and submitted a patch for ebuild for particular compiler. |
72 |
That practically probably never will be happen :) |
73 |
|
74 |
But almost for sure a lot of software will be compiled without any |
75 |
problems with most of major Fortran compiler. And even with almost any |
76 |
widely spread C compilers. Especially if it case of scientific software. |
77 |
I really can't imaging situation, when MPICH will not compile itself and |
78 |
will not compile F90 interface with any non-exotic compiler. I've just |
79 |
never meet such situation. :) |
80 |
|
81 |
One more thing. Lets imaging that next month on market will be available |
82 |
one more C++ or Fortran compiler, which really excellent :) Most of |
83 |
software can be build with it...but... it will take long time to add |
84 |
more flag to USE, change all ebuilds with it and so on. |
85 |
|
86 |
So, there is coming in mind some idea of different approach. Transparent |
87 |
level of multicompiler support. OK, it is not granted. |
88 |
But...scientific guys use to live in not granted world :) |
89 |
It probably looks like: |
90 |
1) You have two more flags: "altcc" and "altfc" |
91 |
2) somewhere (in make.conf for ex) you have specify : |
92 |
ALTCC=C-compiler-which-I-really-like |
93 |
ALTCXX=C++-compiler-which-I-really-like |
94 |
ALTF77=F77-compiler-which-I-really-like |
95 |
ALTF90=F90-compiler-which-I-really-like |
96 |
ALTCFLAGS="optimize-it-to-make-a-rocket" |
97 |
ALTF77LAGS="optimize-it-to-make-a-rocket" |
98 |
|
99 |
and thats all. |
100 |
Ebuild just check for "altcc" and "altfc" flags in USE, if they are, it |
101 |
force configure or whatever else to use it. Thats done. Of course you |
102 |
can't be sure that it will be compiled on all possible alternative |
103 |
compilers, but you can try :) |
104 |
|
105 |
And it make your life really flexible. You do can what you want. Thats |
106 |
Gentoo philosophy, I guess :) |
107 |
|
108 |
It just a general talk, don't kick me if I'm wrong :) |
109 |
|
110 |
Anton Starikov |
111 |
|
112 |
-- |
113 |
gentoo-dev@g.o mailing list |