Bug 299714 – packages should use EAPI=2 & DEPEND="|| ( gcc[fortran] ifc ... ) - was: fortran.eclass should use

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description Dirkjan Ochtman (RETIRED) 2010-01-05 09:46:45 UTC]

I just tried to install dev-python/rpy. This led to a dependency on sci-libs/blas-reference, which failed in a non-standard way because my gcc wasn't compiled with fortran enabled. This should be fixed somehow (i.e. enabling fortran for sys-devel/gcc, then restarting the emerge should be enough to fix it).

[Comment 1 Justin Lecher (RETIRED) 2010-01-05 10:39:10 UTC]

Please attach full build.log and output of emerge --info sci-libs/blas-reference please.
The ebuild uses the fortran.eclass which should check for available fortran compilers and die in case there is none. I this mechanism doesn't work, we have to workout why.

[Comment 2 Dirkjan Ochtman (RETIRED) 2010-01-05 10:42:57 UTC]

It *did* work, it'd just be nice if it used the standard mechanism of doing so (gcc[fortran]) instead of having custom handling that requires taking extra steps.

[Comment 3 Justin Lecher (RETIRED) 2010-01-05 11:46:31 UTC]

(In reply to comment #2)
> It *did* work, it'd just be nice if it used the standard mechanism of doing so
> (gcc[fortran]) instead of having custom handling that requires taking extra
> steps.
> 

As you probably know there are more than one fortran compiler available in the tree. So one is able to compile the package with gcc[-fortran]. Therefor we are using the fortran.eclass to check for available and working fortran compiler. And forcing gcc[fortran] is _no_ solution in that case. So please provide the requested information, so that we can find out, why the eclass didn't die, as you have no working compiler installed.

[Comment 4 Dirkjan Ochtman (RETIRED) 2010-01-05 11:55:21 UTC]

Like I said, it *did* die as wanted.

If there are multiple fortran compilers, why not DEPEND on || ( gcc[fortran] other-compiler )? What does the manual check provide?

[Comment 5 Justin Lecher (RETIRED) 2010-01-05 12:02:48 UTC]

Okay, sorry. I understand it that way, that the emerged failed but the eclass didn't die.

You are right, we should rewrite the eclass to use EAPI="2" and have USEdeps. I will take a look into that.

[Comment 6 Sébastien Fabbro (RETIRED) 2010-01-05 18:05:56 UTC]

(In reply to comment #5)
> You are right, we should rewrite the eclass to use EAPI="2" and have USEdeps. I
> will take a look into that.
> 

I have been trying to avoid the fortran eclass for a while in all ebuilds I touch, it is buggy and obsolete.
But I am not sure enforcing compiler dependency is a good idea. May be we should try to have a mechanism which pulls gcc[fortran] if no fortran compiler is to be found (e.g. as checking that FC or F77 variable compiles a very simple program).
This way we leave it open to any fortran compiler.

[Comment 7 Sébastien Fabbro (RETIRED) 2010-09-28 16:14:19 UTC]

*** Bug 338659 has been marked as a duplicate of this bug. ***

[Comment 8 Justin Lecher (RETIRED) 2011-04-01 10:53:13 UTC]

fortran.eclass isn't used any more in the tree.