Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 299714 - packages should use EAPI=2 & DEPEND="|| ( gcc[fortran] ifc ... ) - was: fortran.eclass should use
Summary: packages should use EAPI=2 & DEPEND="|| ( gcc[fortran] ifc ... ) - was: fortr...
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Science Related Packages
URL:
Whiteboard:
Keywords:
: 338659 (view as bug list)
Depends on:
Blocks: 305637
  Show dependency tree
 
Reported: 2010-01-05 09:46 UTC by Dirkjan Ochtman (RETIRED)
Modified: 2011-04-01 11:07 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dirkjan Ochtman (RETIRED) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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) gentoo-dev 2010-09-28 16:14:19 UTC
*** Bug 338659 has been marked as a duplicate of this bug. ***
Comment 8 Justin Lecher (RETIRED) gentoo-dev 2011-04-01 10:53:13 UTC
fortran.eclass isn't used any more in the tree.