As spyderous suggested on the gentoo-science mailing list, an eclass to check for the presence of a Fortran compiler would uniformise the way we deal with ebuilds requiring Fortran, and would ease our work.
Created attachment 40807 [details] fortran-check.eclass Just a first draft. Ebuilds need only to inherit the eclass to have a check for a Fortran compiler. If a more sophisticated package setup is needed, the ebuild can override pkg_setup() and call fortran-check_pkg_setup() from there.
Created attachment 40812 [details] New fortran.eclass - Kugelfang's propsal My proposal... Thoughts ?
Ok, in order to keep the discussion traceable repostim my message to gentoo-science here.. Well, it would be nice if #57396 would be acted upon finally. That would alleviate like 90% of the complaints we are seeing. BTW, even though its CC'd to seemant I'd rather reassign it to the proper party. Whom should it go to if the change is to happen to make.defaults? Having said that I think that having a fortran eclass would be helpfull too. Oh, and I like that 2nd variant (by Danny) better :). George
Added my version to CVS. It needs some testing now... fortran.eclass features: * need_fortran(profiles) Profiles is a list of possible Fortran Profiles (f77, ifc and f2c atm). * patch_fortran() Searches for Patches that match "${P}-$(basename ${F77})*" and applies them all. * fortran_pkg_setup() This one runs need_fortran(${FORTRAN}. So ebuild only need to set FORTRAN to the list of supported Fortran profiles. No need for pkg_setup in the ebuilds. FORTRAN defaults to "f77". * fortran_src_unpack() Unpacks and runs patch_fortran(). This one can be dangerous with otehr eclasses. E.g. kde.eclass. So fortran.eclass should come very early in inherit.
ECLASS=fortran INHERITED="$INHERITED $ECLASS" These two lines are unneeded. I'd like to see F77 changed to FC. If not, why? Both are currently in use. In my opinion, it is very likely that anyone using a Fortran compiler will be using the same one for all F##. donnie@supernova /usr/local/gentoo-x86/eclass $ grep FC ../app-sci/ -rl | cut -d/ -f2,3 | uniq app-sci/blas app-sci/blas-config app-sci/blas-reference app-sci/gempak app-sci/gwave app-sci/lapack app-sci/lapack-atlas app-sci/lapack-reference app-sci/molden app-sci/scilab app-sci/udunits app-sci/xfoil donnie@supernova /usr/local/gentoo-x86/eclass $ grep F77 ../app-sci/ -rl | cut -d/ -f2,3 | uniq app-sci/blas-atlas app-sci/blas-reference app-sci/lapack-atlas app-sci/lapack-reference app-sci/scilab app-sci/acml app-sci/staden
Donnie: What about checking both FC and F77 ? if they differ, F77 is used. If F77 is empty, FC is used unless it's empty as well.
Yeah, I was thinking that but hadn't had time to comment. Also set both vars as well.
Okay guys. I just commited a new version of fortan.eclass. Donnie: Are you okay with the new F77/FC/F2C tests ? -- I compiled both dev-lang/R and app-sci/octave with this eclass. f77 had no problems like expected. f2c however made linking problems when used to compile octave due to missing MAIN__() function. The far reaching aim for this eclass should IMHO be to DEPEND on "virtual/fortran" . Comments on this ?
OK, here's a few questions, comments: You still don't need the two lines at the top of comment #5. Might want to declare PROFILE as a local, no need to say AVAILABLE="", if you initialize it, it's empty. Does ifc work on emt64? If so, we may need to add amd64 (bad name) to the list. What is this supposed to do? AVAILABLE="${AVAILABLE:1}" It just seems to chops off the first letter of the string, which later can result in fun things printed like: Installed are: 77 f2c i2c Looks like it would break things for anyone using g77, e.g. line 100. But apparently it doesn't somehow, since you said you tested it. Where's the $@ come from? I see you using it, but I don't see where it originates. Lines 59, 83. See the discussion on the lists on EXTRA_ECONF being only for users. You're making the assumption that every configure script with fortran uses --with-f77 rather than --with-fc, which is not the case. See sys-cluster/lam-mpi e.g. Might want PATCHES and PATCH to be local. It's a little confusing to be mixing f77 and g77, might want to use all g77. Other than that, looks good. I haven't tried it though.
a) the two lines... removed :-) b) that available="" is a left over, removed as well. c) it does: AVAILABLE="${AVAILABLE} tag", so there's always a space as the first character. AVAILABLE=${AVAILABLE:1} cuts it of. d) $@ expands to "$1$ "$2" ... "$n" e) i'd say, let's stay with "f77" name instead g77. Two reason: 1. i'm used to it :-D, 2. we'd have to rename ifc as well (ifc is called ifort since version 8.x i think) f) PATCH{ES} local now. g) EXTRA_ECONF: what about something like this: fortran.eclass: f2c_CONF="--with-f2c" f77_CONF="--with-f77" fortran_conf() { echo ${FORTRANC}_CONF } ebuild: f2c_CONF="foo" f77_CONF="bar" ... econf ... $(fortran_conf) h) Nope, there is still no em64t {icc, ifc} available. I already contacted Intel.
c) As discussed on IRC, be _very_ wary of this. Any changes to cause AVAILABLE to have a non-space in the first position will break the eclass. I'd suggest trying to find something more robust. supernova ~ # FOO=" foo bar" supernova ~ # echo $FOO foo bar It appears to be unnecessary anyway so could prolly be pulled. d) I know exactly what $@ does, I just have no clue what it's expanding. Args to need_fortran()? e) It's called ifort? Why do you call it if2 in the eclass then? g) You're missing a ${} in there. You might need to do some fun stuff like `eval echo ${${FORTRANC}_CONF}`. Prolly have a reasonable default in there too, so the ebuild doesn't have to specify if it meets the default. h) Nice work! Way to be on the ball.
c) Here's a more robust idea: ${FOO/[[:space:]]}
Actually that breaks if there isn't a space at the start also: ${FOO/^[[:space:]]} is better
Ok, so what's the status? Is the eclass ready to use? Also, what is the use, just add "inherit 64-bit fortran" and define supported compilers in FORTRAN var inside? Is there anythign else? BTW, I just tried to add fortran.eclass to blas-reference. It tested out Ok, but I would appreciate eclas creator taking a look at the package :). (This is -r1, keyworded -* for now). George
Folks, please see my mail to sci@g.o If you have still have complaints or wishes, please give them here.
Packages that still need to be moved to the new eclass: dev-libs/blitz sci-biology/staden sci-chemistry/molden sci-libs/blas-reference sci-libs/lapack-atlas sci-libs/lapack-reference sci-libs/plplot sci-libs/scipy sci-mathematics/octave sci-mathematics/scilab sci-misc/camfr
Blitz, scipy and camfr updated.
Fixed: sci-biology/staden sci-libs/blas-reference sci-libs/lapack-atlas sci-libs/lapack-reference sci-mathematics/octave sci-mathematics/scilab Remaining: sci-chemistry/molden (spyderous) sci-libs/plplot (cryos) We also need to add a gfortran profile to fortran.eclass for gcc4.
(In reply to comment #18) > sci-chemistry/molden (spyderous) I'll get to this soon, but it's still not entirely clear to me how the eclass is meant to be used. Could someone point out examples for these cases? 1) any fortran compiler works, fortran is mandatory 2) only a couple of fortran compilers work, fortran is mandatory 3) any compiler works, fortran is optional When configure scripts accept environment values for F77 or FC, how are these supposed to get set in the ebuild? > We also need to add a gfortran profile to fortran.eclass for gcc4. Indeed; there's an mpich2 ebuild in progress that will require gfortran. So it would be nice to perhaps have a check like "if we're using gcc, then we need >=gcc-4 if gfortran is required or in use."
Donnie: Start with "inherit fortran". This will redefine "pkg_setup" to test for the g77 Fortran compiler. If you know your package will also compile with f2c or ifc (the only other available profiles at this time), define something like FORTRAN="g77 f2c ifc" after inheriting the eclass. If you already define "src_unpack" in the ebuild, the test will not happen automatically, of course, so you need to call "need_fortran" inside "pkg_setup", with the valid profiles as arguments (for example: "need_fortran g77"). When Fortran support is optional, you can use the following inside "pkg_setup": if use fortran; then need_fortran g77 ifc f2g fi Unless I am mistaken, ebuilds should never set F77 or FC, but rather leave it to the user to specify the appropriate compiler. (This is what is done with CC/CXX.) "fortran.eclass" ensures an appropriate compiler is present, but will not choose the compiler for the user. (I think we rely on g77 being the default. If users want to change that, they likely know what they are doing.)
(In reply to comment #20) > Start with "inherit fortran". This will redefine "pkg_setup" to test for the > g77 Fortran compiler. If you know your package will also compile with f2c or > ifc (the only other available profiles at this time), define something like > FORTRAN="g77 f2c ifc" after inheriting the eclass. If you already define > "src_unpack" in the ebuild, the test will not happen automatically, of course, > so you need to call "need_fortran" inside "pkg_setup", with the valid profiles > as arguments (for example: "need_fortran g77"). Why just call need_fortran instead of calling fortran-pkg_setup within pkg_setup()? That would ensure that any later changes also get integrated. > Unless I am mistaken, ebuilds should never set F77 or FC, but rather leave it > to the user to specify the appropriate compiler. (This is what is done with > CC/CXX.) "fortran.eclass" ensures an appropriate compiler is present, but will > not choose the compiler for the user. (I think we rely on g77 being the > default. If users want to change that, they likely know what they are doing.) OK. I see sci-misc/xfoil doing weird things with FC=$FORTRANC and sci-libs/blas-reference setting FC manually.
(In reply to comment #21) (I meant pkg_setup when I said src_unpack in comment #20.) > Why just call need_fortran instead of calling fortran-pkg_setup within > pkg_setup()? That would ensure that any later changes also get integrated. Yes, that would be even better, I think. Once all packages are moved to the new system, I will review all ebuilds inheriting fortran.eclass and change that.
Created attachment 73772 [details, diff] molden-4.3-fortran.patch spyderous: Suggested patch for molden-4.3. Would you be Ok with my committing it?
Created attachment 73774 [details, diff] plplot-5.5.2-fortran.patch cryos: Suggested patch for plplot. Would you be Ok with my committing it?
(In reply to comment #23) > Created an attachment (id=73772) [edit] > molden-4.3-fortran.patch > > spyderous: > > Suggested patch for molden-4.3. Would you be Ok with my committing it? This section of the ebuild is still weird: # Set fortran compiler, since gcc-config doesn't [ -z ${FC} ] && FC="g77" Should probably get fixed to pass the correct FC in the make call instead. BTW, how's tc-getF77() from toolchain-funcs.eclass relate to all the fortran.eclass stuff?
Dunno if any of you happen to use nano, but I created some syntax highlighting rules for the eclass to make things easier for me. The first part checks the FORTRAN variable at the top for valid values, and the second part checks for uses of FORTRANC or fortran CFLAGS/compilers later on. syntax "ebuild" "\.e(build|class)$" # Fortran -- needs to be before = color magenta "FORTRAN=\"(g77|ifc|f2c) ?(g77|ifc|f2c)? ?(g77|ifc|f2c)?\"" # Fix quotes from FORTRAN color white "\"" ... C(XX)?FLAGS stuff ... # More fortran color red "\<FORTRAN(C)?\>" "\<FFLAGS\>" "\<F(C|77|90)\>"
> This section of the ebuild is still weird: > # Set fortran compiler, since gcc-config doesn't > [ -z ${FC} ] && FC="g77" Yes, this should probably be simply FC="$(tc-getF77)". > BTW, how's tc-getF77() from toolchain-funcs.eclass relate to all the > fortran.eclass stuff? I think they are separate things. The fortran eclass just works around a Portage limitation to enforce dependency on a Fortran compiler. The user is still free to choose the compiler he likes and is responsible for setting F77 in "make.conf" to something that is installed on his system. The only place where the two systems could cross, I think, is that the fortran eclass could check the value of F77 and die with an error if the selected compiler does not work with the package. (Maybe the fortran eclass could also be extended to die if the selected compiler is not installed but that is taking the user by the hand quite a bit.) Another thing I would like to see is the possibility to ignore the compiler check to allow users to try any compiler they wish and, eventually, tell us if they were successful. (Something like "IGNORE_FORTRAN_CHECK='1' F77='icc' emerge plplot".) That TODO list is growing... :)
(In reply to comment #27) > Yes, this should probably be simply FC="$(tc-getF77)". I think using tc-getF77 may not be the best idea because FORTRAN may not include g77, which is the default of tc-getF77. I've been using FC="${FORTRANC}", which relies on fortran.eclass for its value. So in an admittedly weird scenario, F77 is not set and the package will not compile with g77 so FORTRAN="ifc f2c", for example. Then fortran.eclass thinks we're using ifc, but tc-getF77 thinks we're using g77. This could cause annoying issues. > I think they are separate things. The fortran eclass just works around a > Portage limitation to enforce dependency on a Fortran compiler. The user is > still free to choose the compiler he likes and is responsible for setting F77 > in "make.conf" to something that is installed on his system. The only place > where the two systems could cross, I think, is that the fortran eclass could > check the value of F77 and die with an error if the selected compiler does > not work with the package. (Maybe the fortran eclass could also be extended to > die if the selected compiler is not installed but that is taking the user by > the hand quite a bit.) Isn't that already the case if the selected compiler isn't in FORTRAN? > Another thing I would like to see is the possibility to > ignore the compiler check to allow users to try any compiler they wish > and, eventually, tell us if they were successful. (Something like > "IGNORE_FORTRAN_CHECK='1' F77='icc' emerge plplot".) Probably would be useful if they could just ignore the FORTRAN setting in the ebuild and run FORTRAN="their compiler" emerge foo.
I'd like to have a way to select the FC inside of an ebuild. For example an application can be compiled with ifc and g95, but needs different cmd line flags. Then I would like to set the compiler to use based on a useflag (ifc). Currently the eclass just checks for the default FC and if it is not in the scope of allowed FCs for this ebuild it dies. So it should be possible to either deactivate this check from inside the ebuild, if the ebuild will handle the invocation of the correct FC.
I would like to see a gfortran profile added - any objections to that going in? I would also like to see similar behaviour to that before the eclass where the best fortran compiler was chosen rather than failing. I think that it should default to g77, and gfortran if g77 is not present. If the ifc use flag is specified and the ebuild accepts it then that should be the default (if that makes sense). Kugelfang and I talked about this on IRC but I thought may be some of it should be written down while I remember :) It does seem that some of our packages are regressing in their behaviour after the moves to the new eclass. So we should document this behaviour for our users somewhere, or fix the eclass to be more automated (I prefer more automation). What do others think?
(In reply to comment #30) > I would like to see a gfortran profile added - any objections to that going in? > I would also like to see similar behaviour to that before the eclass where the > best fortran compiler was chosen rather than failing. I think that it should > default to g77, and gfortran if g77 is not present. If the ifc use flag is > specified and the ebuild accepts it then that should be the default (if that > makes sense). I still don't understand why you want to default to g77 first, then gfortran. On any system with gfortran that's obviously what people will want to use before g77. We need to get rid of the ifc USE flag, it's an abomination. ifc should be controlled through the F(C|77|90) variables.
> We need to get rid of the ifc USE flag, it's an abomination. ifc should be controlled through the F(C|77|90) variables. I herbly object this, as it is possible to set useflags for individual ebuilds and this is not possible with the environment-variables. So if you just want to have some programmes built with ifc, then it would become a real pita to upgrade the system.
(In reply to comment #32) > > We need to get rid of the ifc USE flag, it's an abomination. ifc should be > controlled through the F(C|77|90) variables. > > I herbly object this, as it is possible to set useflags for individual ebuilds > and this is not possible with the environment-variables. So if you just want to > have some programmes built with ifc, then it would become a real pita to > upgrade the system. Then another way needs to be found. This way is wrong.
(In reply to comment #33) > > Then another way needs to be found. This way is wrong. > Not only wrong: it does not work. Enabling "icc" does not set the CC environment variable, so you currently need to do both: set the environment variable *and* the USE flag. USE flags are for optional features in a package, not for compiler selection. If you need package specific environment variables, bug the Portage team, and use some bashrc tricks in the meantime.
Hey guys, thanx for working on fortran code for gentoo. I'm using ifort (intel's fortran compiler, was called ifc before) and now PGI's set of compilers. The eclass doesn't seems to support something else than fortran 77 with g77 and f2c. ifc is now called ifort and supports fortran 90/95 (even some 2003). What should be done to make possible the use of pgi's? Is it only a something like modifying fortran.eclass? Or the profiles in it are stored somewhere else? Thanx
(In reply to comment #35) > Is it only a something like modifying fortran.eclass? Or the profiles in it are > stored somewhere else? Everything is the eclass. (And we do need more profiles...)
Created attachment 77137 [details, diff] fortran.eclass.diff - proposed change to eclass Here is a proposed change to the fortran eclass. This relates to bug 108781 and other ebuilds where previous behaviour has changed. Ebuilds using fortran have become less easily useable due to the automatic selection of an appropriate compiler being taken away. Using this patched eclass gfortran was automatically selected on my gcc4.0 system, whilst g77 was automatically selected on my gcc3.4 system. This approach can be extended by adding in more elifs defining a default priority order when the user has not selected a fortran compiler previously. Any objections to me adding this patch to the tree?
(In reply to comment #37) > Created an attachment (id=77137) [edit] > > Any objections to me adding this patch to the tree? > Hi Marcus, The patch looks fine to me, even though I haven't been able to try it out since my system is still lacking gcc-4.0.x. The only thing that came to mind would be to make the error messages (lines 88 and 91 in the patched ebuild) somewhat more precise, i.e. "eerror.... emerge sys-devel/gcc-4.*" "eerror.....emerge sys-devel/gcc-3.*" or sth along these lines. Thanks, Markus
I think it would be better if we could simply retrieve the selected/default Fortran compiler from tc-getF77 in the toolchain-funcs eclass. So perhaps the fix to default to gfortran if gcc 4 is installed could be put in that eclass instead? Maybe getF77 is not an appropriate name now that gcc 4 supports fortran 77/90/95 (I think), so a new function would be better? Also, we should probably add something to the make.conf man page to explain that MY_FORTRAN can be used to select a fortran compiler. (And while on the topic, why not simply FORTRAN, FORTRANC or FC? Why MY_FORTRAN?)
(In reply to comment #39) > I think it would be better if we could simply retrieve the selected/default > Fortran compiler from tc-getF77 in the toolchain-funcs eclass. So perhaps the > fix to default to gfortran if gcc 4 is installed could be put in that eclass > instead? Maybe getF77 is not an appropriate name now that gcc 4 supports > fortran 77/90/95 (I think), so a new function would be better? Changes definitely shouldn't be made to toolchain-funcs without passing through the maintainers. > Also, we should probably add something to the make.conf man page to explain > that MY_FORTRAN can be used to select a fortran compiler. (And while on the > topic, why not simply FORTRAN, FORTRANC or FC? Why MY_FORTRAN?) You can set FC. if [ -n "${F77}" -o -n "${FC}" -o -n "${F2C}" ]; then if [ -n "${F77}" ]; then FC="${F77}" # F77 overwrites FC fi if [ -n "${FC}" -a -n "${F2C}" ]; then ewarn "Using ${FC} and f2c is impossible. Disabling F2C !" F2C="" # Disabling f2c MY_FORTRAN="$(basename ${FC})" # set MY_FORTRAN to filename of # the Fortran Compiler
Markus: I had thought of doing that originally, but was not certain. I have added it in now as I believe the verbosity can only help. Olivier: I see where you are coming from, but the move to the eclass has removed functionality that was already present in the ebuilds before the move. I think this patch is a good solution right now, but may be in the longer term we talk to toolchain about this. I had a look and it does not look like they have really taken the fortran changes into account yet. I have committed a slightly updated version of the patch I proposed. Please take a look. I tested it here with my GCC 3.4 and my GCC 4.0 systems with no side effects. This seems the sanest way to improve default behaviour for now, but could probably be further improved. I like Donnie's idea of a default selection order of the available compilers, may be allowing users to set their preferred order too. GCC 4.0 will be entering the testing branch very soon though, and so I felt it was necessary to get a reasonable solution into the tree sooner rather than later. I still welcome any feedback on this or any other changes I have made.
I just fixed the gfortran patch. It missed a part about setting FORTRANC. I'm playing with blas-atlas and lapack-atlas with gfortran now -- got blas-atlas working fine, still screwing around with lapack. Can't find any bugs about either yet.
(In reply to comment #42) > I'm playing with blas-atlas and lapack-atlas with gfortran now -- got > blas-atlas working fine, still screwing around with lapack. Can't find any bugs > about either yet. Just got lapack-atlas working. A call to gcc-major-version() was getting screwed up because of an earlier setting of CC to an invalid CC value for hacking around the build system.
Something's a bit screwed up with our handling of the F77 and FC variables, but it hasn't hit us yet. FC should be for Fortran90 code, F77 for Fortran77 code. They shouldn't be overwriting each other and should get set up independently for use in ebuilds. Also this could use an enhancement to allow passing in arbitrary Fortran compilers that aren't yet in the allowed compilers list for that ebuild.
Created attachment 96435 [details, diff] Adding of PGI compilers (pgf90 & pgf77) (In reply to comment #44) > Something's a bit screwed up with our handling of the F77 and FC variables, but > it hasn't hit us yet. FC should be for Fortran90 code, F77 for Fortran77 code. > They shouldn't be overwriting each other and should get set up independently > for use in ebuilds. > > Also this could use an enhancement to allow passing in arbitrary Fortran > compilers that aren't yet in the allowed compilers list for that ebuild. > I tryed to emerge gentoo-science's openmpi using Portland Group's set of compiler (PGI's pgf90 and pgf77). I did: CC="pgcc" CXX="pgCC" F77="pgf77" FC="pgf90" emerge -av sys-cluster/openmpi but the fortran.eclass doesn't support those compilers. I added them with the patch above. I also encontered problems with F77 overwriting FC. The patch contain a workwaround for PGI compilers.
(In reply to comment #45) > > Also this could use an enhancement to allow passing in arbitrary Fortran > > compilers that aren't yet in the allowed compilers list for that ebuild. > > > I tryed to emerge gentoo-science's openmpi using Portland Group's set of > compiler (PGI's pgf90 and pgf77). I did: > CC="pgcc" CXX="pgCC" F77="pgf77" FC="pgf90" emerge -av sys-cluster/openmpi > but the fortran.eclass doesn't support those compilers. I added them with the > patch above. Yeah this needs to get fixed properly with a compiler override to use "unsupported" compilers. > I also encontered problems with F77 overwriting FC. The patch contain a > workwaround for PGI compilers. This was just done incorrectly in the first place. FC should be used for Fortran 90/95 and F77 for Fortran 77. Probably just having a $FORTRANC variable to use is also incorrect.
I am confused about how to use the fortran.eclass. Do I use $MY_FORTRAN? $FC? $F77? Could some guidance be added to the man page? What would be really helpful is if all of the environment variables FC/FCFLAGS/FCLIBS OR F77/FFLAGS/FLIBS be set accordingly to the following standards used by autoconf: http://www.gnu.org/software/autoconf/manual/html_node/Fortran-Compiler.html Another helpful feature would be for the 'debug' USE variable to set the FCFLAGS or FFLAGS variable appropriately for the compiler selected (for example: FCFLAGS='-g' for FC='gfortran' if debug set, otherwise FCFLAGS='-O2') Thanks, Tim P.S. Shouldn't the 'Component' for the bug be 'Eclasses and Profiles'?
How to use: 1) inherit fortran 2) Set FORTRAN="gfortran ifc" for list of working compilers 3) If you set your own pkg_setup(), run fortran_pkg_setup() in it 4) Use the $FORTRANC variable to force the Fortran compiler in whatever way needed if the package doesn't respect a user's FC/F77 setting. 4) is the really bad part, we need to split FORTRANC up properly for F77 and F90/95/03 using F77 and FC variables. A patch to do this would be useful.
Finally the fortran.eclass is going to be removed. Marking obsolete.
