*This bug should be duplicated when packages cannot find a valid fortran compiler.* Problem: Currently we have no instrument to check whether FC and F77 are valid fortran compiler. Explanation: We support users choice of fortran compiler. There are two compiler supported by portage, gfortran via sys-devel/gcc[fortran] and ifort via dev-lang/ifc. But every other user installation is supported. Only FC and/or F77 need to be exported pointing to the compiler. Because of this, it is not a solution to depend on sys-devel/gcc[fortran] or || (sys-devel/gcc[fortran] dev-lang/ifc) for the simple reason, that sys-devel/gcc[fortran] could be emerged but FC is set to FC=ifort. In this case the dependency is fullfilled but the compile fails. Similar constellations are possible. Currently fortran is in the default USE set in all profiles except hardened, so the average user should not change this and won't have a problem. Future: Find a solution to check for valid fortran compiler. Perhaps together with toolchain guys.
*** Bug 246389 has been marked as a duplicate of this bug. ***
*** Bug 292408 has been marked as a duplicate of this bug. ***
*** Bug 305637 has been marked as a duplicate of this bug. ***
@toolchain In future we need to work together on a solution to check for the validity of compilers, especially fortran.
*** Bug 352664 has been marked as a duplicate of this bug. ***
Why don't you create a virtual/fortran then, or even virtual/fortran_std or something, if you want an apparent indication that this is for some "standard" fortran implementation? Then make all packages that need it depend on this virtual. I do the same with Ada and it works fine. Of course, being ada, the "complete" compilers are pretty much standard compliant, so the set includes all (avaliable in portage) Ada compilers. By providing that (restricted) virtual you are pretty much recreating a situation with having a marked core set of fortran compilers on which one can rely.. Separate compilers most likely can be installed in parallel and switched on the fly (I do this even for different major versions of the same Ada compiler, similarly to a SLOTted gcc), so I don't see the reason for "excessive interaction" to be a problem either. And dynamic switching of compilers (if you want to have one "active" but also to be able to quickly switch to another one), can be restricted to this subset too..
We like to leave the choice of fortran compiler to the user, eg portland or what ever. Those are not in portage so no virtual would catch them. The only scenario what I could think of is: * virtual with || (gcc[fortan] ifc) * testing which is available for fallback * simple compile test on current $FC/F77 or tc-getFC/F77 * if failed, defaulting on the fallback determined above. This would let the user the choice to select a non portage compiler. Using /et/portage/profile/package.provided it is possible to avoid having gfortran or ifort around.
I will add a virtual/fortran. This sounds as a good idea to me.
(In reply to comment #7) > We like to leave the choice of fortran compiler to the user, eg portland or > what ever. Those are not in portage so no virtual would catch them. > > The only scenario what I could think of is: > > * virtual with || (gcc[fortan] ifc) > * testing which is available for fallback > * simple compile test on current $FC/F77 or tc-getFC/F77 > * if failed, defaulting on the fallback determined above. > > This would let the user the choice to select a non portage compiler. Using > /et/portage/profile/package.provided it is possible to avoid having gfortran or > ifort around. What about something like dev-lang/native-fortan in the virtual (in the style of sys-cluster/native-mpi) ?
Not necessary. the only thing we need to fix is, what happens if only ifort is there. Would tc-getFC get ifort, without exporting fc=ifort?
(In reply to comment #7) > We like to leave the choice of fortran compiler to the user, eg portland or > what ever. Those are not in portage so no virtual would catch them. The suggested virtual was only for "standard" ones, which are in portage and behave as expected, pretty much exactly like what you described in detail under "the only scenario" :). That's why I suggested it may make sense to call it "fortran-std" or something instead of plain "fortran".
Please use fortran-2.eclass from now on.
