| Summary: | packages cannot find a valid fortran compiler | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Justin Lecher (RETIRED) <jlec> |
| Component: | Current packages | Assignee: | Gentoo Science Related Packages <sci> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bug, disp.reg.bugs.gentoo, nikoli, pille+bugs.gentoo.org, toolchain |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 366243 | ||
| Bug Blocks: | |||
|
Description
Justin Lecher (RETIRED)
2011-04-01 12:31:31 UTC
*** 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. |