Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=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 an attachment (id=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 an attachment (id=73772) [details]
molden-4.3-fortran.patch

spyderous:

Suggested patch for molden-4.3. Would you be Ok with my committing it?

Created an attachment (id=73774) [details]
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] [details]
> 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 an attachment (id=77137) [details]
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] [details]
> 
> 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 an attachment (id=96435) [details]
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.