[gentoo-dev] Please review fortran-2.eclass

[gentoo-dev] Please review fortran-2.eclass

[justin]

[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]

Hi all,

please review and comment the attached eclass.

Purpose of this eclass is the correct setting of a working fortran
compiler. There are numerous bugs which suffer from one or the other
defect here. Anybody who touch a fortran package knows what I am talking
about.
Currently we support two fortran compilers in the tree, soonish there
will be three. But we also like to like to allowed any out-of-tree
compiler. So depending on gcc[fortran] or virtual/fortran doesn't
fullfill the needs for one or the other reason, which I will not
elaborate again.

Our solution:
1. Depend on virtual/fortran. This will force the ordinary user to use
gfortran through gcc[fortran]. Or the intel compiler has to be selected
via FC=ifort. With this also any other solution can be selected.

2. Test whether FC is a working fortran compiler. Why? gcc:4.5[fortran]
and gcc:4.6[-fortran] can be emerged and gcc-4.6 selected. Thereby
virtual/fortran dependdencies are fullfiled but no working compiler is
there. Same happens in many other constellations.

3. Test for openmp support. For a mixture of the above reasons, it is
impossible to depend on openmp capabilities if user do change anything
from default.

4. Get_fcomp is needed for some packages which do not work with the full
name, e.g. seperate makefiles for intel and gnu compiler.

5. Once FC is working, set all other variable possibly defining fortran
compilers of any flavour to FC.

6. It is still possible without any change to ebuilds to integrate the
test functions in the toolchain-funcs eclass later, if we decide this is
a better way to handle those functions.

Thanks for attention,  justin

[-- Attachment #2: fortran-2.eclass --]
[-- Type: text/plain, Size: 3011 bytes --]

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# Author Justin Lecher <jlec@gentoo.org>
# Test functions provided by Sebastien Fabbro and Kacper Kowalik

# @ECLASS: fortran-2.eclass
# @MAINTAINER:
# jlec@gentoo.org
# sci@gentoo.org
# @BLURB: Packages, which need a fortran compiler should inherit this eclass.
# @DESCRIPTION:
# If you need a fortran compiler, inherit this eclass. This eclass tests for
# working fortran compilers. Optional, it checks for openmp capability of the
# current fortran compiler through FC_NEED_OPENMP=1.
# Only phase function exported is pkg_setup.

# @ECLASS-VARIABLE: FC_NEED_OPENMP
# @DESCRIPTION:
# Set FC_NEED_OPENMP=1 in order to test FC for openmp capabilities
#
# Default is 0

inherit toolchain-funcs

DEPEND="virtual/fortran"
RDEPEND="${DEPEND}"

# internal function
#
# FUNCTION: _have-valid-fortran
# DESCRIPTION:
# Check whether FC returns a working fortran compiler
_have-valid-fortran() {
	local base=${T}/test-tc-fortran
	cat <<- EOF > "${base}.f"
	       end
	EOF
	$(tc-getFC "$@") "${base}.f" -o "${base}" >&/dev/null
	local ret=$?
	rm -f "${base}"*
	return ${ret}
}

# internal function
#
# FUNCTION: _fortran-has-openmp
# DESCRIPTION:
# See if the fortran supports OpenMP.
_fortran-has-openmp() {
	local flag
	case $(tc-getFC) in
		*gfortran*|pathf*)
			flag=-fopenmp ;;
		ifort)
			flag=-openmp ;;
		mpi*)
			local _fcomp=$($(tc-getFC) -show | awk '{print $1}')
			FC=${_fcomp} _fortran-has-openmp
			return $? ;;
		*)
			return 0 ;;
	esac
	local base=${T}/test-fc-openmp
	# leave extra leading space to make sure it works on fortran 77 as well
	cat <<- EOF > "${base}.f"
       call omp_get_num_threads
       end
	EOF
	$(tc-getFC "$@") ${flag} "${base}.f" -o "${base}" >&/dev/null
	local ret=$?
	rm -f "${base}"*
	return ${ret}
}

# @FUNCTION: get_fcomp
# @DESCRIPTION:
# Returns the canonical name or the native compiler of the current fortran compiler
#
# e.g.
#
# x86_64-linux-gnu-gfortran -> gfortran
get_fcomp() {
	case $(tc-getFC) in
		*gfortran* )
			echo "gfortran" ;;
		ifort )
			echo "ifc" ;;
		pathf*)
			echo "pathcc" ;;
		mpi*)
			local _fcomp=$($(tc-getFC) -show | awk '{print $1}')
			echo $(FC=${_fcomp} get_fcomp) ;;
		* )
			echo $(tc-getFC) ;;
	esac
}

# @FUNCTION: fortran-2_pkg_setup
# @DESCRIPTION:
# Setup functionallity, checks for a valid fortran compiler and optionally for its openmp support.
fortran-2_pkg_setup() {
	_have-valid-fortran || \
		die "Please emerge the current gcc with USE=fortran or export FC defining a working fortran compiler"
	export FC=$(tc-getFC)
	export F77=$(tc-getFC)
	export F90=$(tc-getFC)
	export F95=$(tc-getFC)
	if [[ ${FC_NEED_OPENMP} == 1 ]]; then
		_fortran-has-openmp || \
		die "Please emerge current gcc with USE=openmp or export FC with compiler that supports OpenMP"
	fi
}

EXPORT_FUNCTIONS pkg_setup

Re: [gentoo-dev] Please review fortran-2.eclass

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

On 6/13/11 11:06 AM, justin wrote:
> # @FUNCTION: fortran-2_pkg_setup
> # @DESCRIPTION:
> # Setup functionallity, checks for a valid fortran compiler and optionally for its openmp support.
> fortran-2_pkg_setup() {
> 	_have-valid-fortran || \
> 		die "Please emerge the current gcc with USE=fortran or export FC defining a working fortran compiler"
> 	export FC=$(tc-getFC)
> 	export F77=$(tc-getFC)
> 	export F90=$(tc-getFC)
> 	export F95=$(tc-getFC)
> 	if [[ ${FC_NEED_OPENMP} == 1 ]]; then
> 		_fortran-has-openmp || \
> 		die "Please emerge current gcc with USE=openmp or export FC with compiler that supports OpenMP"
> 	fi
> }
> 
> EXPORT_FUNCTIONS pkg_setup

I wonder if it's possible to take advantage of EAPI4's pkg_pretend, and
fall back to pkg_setup for older EAPIs. pkg_pretend makes it possible to
fix the setup before running emerge, instead of things breaking in the
middle.

It's just a suggestion.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] Please review fortran-2.eclass

[justin]

On 6/13/11 11:19 AM, "Paweł Hajdan, Jr." wrote:
> On 6/13/11 11:06 AM, justin wrote:
>> # @FUNCTION: fortran-2_pkg_setup
>> # @DESCRIPTION:
>> # Setup functionallity, checks for a valid fortran compiler and optionally for its openmp support.
>> fortran-2_pkg_setup() {
>> 	_have-valid-fortran || \
>> 		die "Please emerge the current gcc with USE=fortran or export FC defining a working fortran compiler"
>> 	export FC=$(tc-getFC)
>> 	export F77=$(tc-getFC)
>> 	export F90=$(tc-getFC)
>> 	export F95=$(tc-getFC)
>> 	if [[ ${FC_NEED_OPENMP} == 1 ]]; then
>> 		_fortran-has-openmp || \
>> 		die "Please emerge current gcc with USE=openmp or export FC with compiler that supports OpenMP"
>> 	fi
>> }
>>
>> EXPORT_FUNCTIONS pkg_setup
> 
> I wonder if it's possible to take advantage of EAPI4's pkg_pretend, and
> fall back to pkg_setup for older EAPIs. pkg_pretend makes it possible to
> fix the setup before running emerge, instead of things breaking in the
> middle.
> 
> It's just a suggestion.
> 

You are right. Thought about it, but refused it, because I din't want to
force EAPI=4. But right I can just use a fall back for EAPI<4. Thanks
for the suggestion.

Re: [gentoo-dev] Please review fortran-2.eclass

[justin]

[-- Attachment #1.1: Type: text/plain, Size: 1069 bytes --]

On 6/13/11 11:19 AM, "Paweł Hajdan, Jr." wrote:
> On 6/13/11 11:06 AM, justin wrote:
>> # @FUNCTION: fortran-2_pkg_setup
>> # @DESCRIPTION:
>> # Setup functionallity, checks for a valid fortran compiler and optionally for its openmp support.
>> fortran-2_pkg_setup() {
>> 	_have-valid-fortran || \
>> 		die "Please emerge the current gcc with USE=fortran or export FC defining a working fortran compiler"
>> 	export FC=$(tc-getFC)
>> 	export F77=$(tc-getFC)
>> 	export F90=$(tc-getFC)
>> 	export F95=$(tc-getFC)
>> 	if [[ ${FC_NEED_OPENMP} == 1 ]]; then
>> 		_fortran-has-openmp || \
>> 		die "Please emerge current gcc with USE=openmp or export FC with compiler that supports OpenMP"
>> 	fi
>> }
>>
>> EXPORT_FUNCTIONS pkg_setup
> 
> I wonder if it's possible to take advantage of EAPI4's pkg_pretend, and
> fall back to pkg_setup for older EAPIs. pkg_pretend makes it possible to
> fix the setup before running emerge, instead of things breaking in the
> middle.
> 
> It's just a suggestion.
> 

Now using the new pkg_pretend for EAPI=4

[-- Attachment #1.2: fortran-2.eclass --]
[-- Type: text/plain, Size: 3262 bytes --]

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# Author Justin Lecher <jlec@gentoo.org>
# Test functions provided by Sebastien Fabbro and Kacper Kowalik

# @ECLASS: fortran-2.eclass
# @MAINTAINER:
# jlec@gentoo.org
# sci@gentoo.org
# @BLURB: Packages, which need a fortran compiler should inherit this eclass.
# @DESCRIPTION:
# If you need a fortran compiler, inherit this eclass. This eclass tests for
# working fortran compilers. Optional, it checks for openmp capability of the
# current fortran compiler through FC_NEED_OPENMP=1.
# Only phase function exported is pkg_setup.

# @ECLASS-VARIABLE: FC_NEED_OPENMP
# @DESCRIPTION:
# Set FC_NEED_OPENMP=1 in order to test FC for openmp capabilities
#
# Default is 0

inherit toolchain-funcs

DEPEND="virtual/fortran"
RDEPEND="${DEPEND}"

# internal function
#
# FUNCTION: _have-valid-fortran
# DESCRIPTION:
# Check whether FC returns a working fortran compiler
_have-valid-fortran() {
	local base=${T}/test-tc-fortran
	cat <<- EOF > "${base}.f"
	       end
	EOF
	$(tc-getFC "$@") "${base}.f" -o "${base}" >&/dev/null
	local ret=$?
	rm -f "${base}"*
	return ${ret}
}

# internal function
#
# FUNCTION: _fortran-has-openmp
# DESCRIPTION:
# See if the fortran supports OpenMP.
_fortran-has-openmp() {
	local flag
	case $(tc-getFC) in
		*gfortran*|pathf*)
			flag=-fopenmp ;;
		ifort)
			flag=-openmp ;;
		mpi*)
			local _fcomp=$($(tc-getFC) -show | awk '{print $1}')
			FC=${_fcomp} _fortran-has-openmp
			return $? ;;
		*)
			return 0 ;;
	esac
	local base=${T}/test-fc-openmp
	# leave extra leading space to make sure it works on fortran 77 as well
	cat <<- EOF > "${base}.f"
       call omp_get_num_threads
       end
	EOF
	$(tc-getFC "$@") ${flag} "${base}.f" -o "${base}" >&/dev/null
	local ret=$?
	rm -f "${base}"*
	return ${ret}
}

# @FUNCTION: get_fcomp
# @DESCRIPTION:
# Returns the canonical name or the native compiler of the current fortran compiler
#
# e.g.
#
# x86_64-linux-gnu-gfortran -> gfortran
get_fcomp() {
	case $(tc-getFC) in
		*gfortran* )
			echo "gfortran" ;;
		ifort )
			echo "ifc" ;;
		pathf*)
			echo "pathcc" ;;
		mpi*)
			local _fcomp=$($(tc-getFC) -show | awk '{print $1}')
			echo $(FC=${_fcomp} get_fcomp) ;;
		* )
			echo $(tc-getFC) ;;
	esac
}

# @FUNCTION: fortran-2_pkg_pretend
# @DESCRIPTION:
# Setup functionallity, checks for a valid fortran compiler and optionally for its openmp support.
fortran-2_pkg_pretend() {
	_have-valid-fortran || \
		die "Please emerge the current gcc with USE=fortran or export FC defining a working fortran compiler"
	export FC=$(tc-getFC)
	export F77=$(tc-getFC)
	export F90=$(tc-getFC)
	export F95=$(tc-getFC)
	if [[ ${FC_NEED_OPENMP} == 1 ]]; then
		_fortran-has-openmp || \
		die "Please emerge current gcc with USE=openmp or export FC with compiler that supports OpenMP"
	fi
}


# @FUNCTION: fortran-2_pkg_setup
# @DESCRIPTION:
# Setup functionallity, checks for a valid fortran compiler and optionally for its openmp support, used in EAPI < 4.
fortran-2_pkg_setup() {
	has ${EAPI:-0} 0 1 2 3 && fortran-2_pkg_pretend
}

case "${EAPI:-0}" in
	0|1|2|3)
		EXPORT_FUNCTIONS pkg_setup;;
	4)
		EXPORT_FUNCTIONS pkg_pretend;;
	*) die "EAPI=${EAPI} is not supported" ;;
esac

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]

[gentoo-dev] write to filesystem in pkg_pretend

[Torsten Veller]

* justin <jlec@gentoo.org>:
> Now using the new pkg_pretend for EAPI=4

While T is defined in all phases, PMS also says that "pkg_pretend must
not write to the filesystem".

Is it allowed to write to T or not? Can the specs be clearer if it's allowed?

-- 
Thanks

Re: [gentoo-dev] write to filesystem in pkg_pretend

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Fri, 17 Jun 2011 18:25:21 +0200
Torsten Veller <ml-en@veller.net> wrote:

> * justin <jlec@gentoo.org>:
> > Now using the new pkg_pretend for EAPI=4
> 
> While T is defined in all phases, PMS also says that "pkg_pretend must
> not write to the filesystem".
> 
> Is it allowed to write to T or not? Can the specs be clearer if it's
> allowed?

No, it's not allowed. pkg_pretend() should work without creating
the ebuild temporary dirs. But that's only my PoV.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] write to filesystem in pkg_pretend

[Ulrich Mueller]

>>>>> On Fri, 17 Jun 2011, Torsten Veller wrote:

> While T is defined in all phases, PMS also says that "pkg_pretend
> must not write to the filesystem".

> Is it allowed to write to T or not? Can the specs be clearer if it's
> allowed?

"Must not write to the filesystem" seems to be very clear to me.

Ulrich

Re: [gentoo-dev] write to filesystem in pkg_pretend

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 477 bytes --]

On Friday, June 17, 2011 12:25:21 Torsten Veller wrote:
> * justin <jlec@gentoo.org>:
> > Now using the new pkg_pretend for EAPI=4
> 
> While T is defined in all phases, PMS also says that "pkg_pretend must
> not write to the filesystem".
> 
> Is it allowed to write to T or not? Can the specs be clearer if it's
> allowed?

sounds like a good reason to use emktemp as that'll utilize /tmp for files 
when $T is unavailable

or just drop EAPI=4 support ;)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] write to filesystem in pkg_pretend

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

On 17.06.2011 20:18, Mike Frysinger wrote:
> On Friday, June 17, 2011 12:25:21 Torsten Veller wrote:
>> * justin <jlec@gentoo.org>:
>>> Now using the new pkg_pretend for EAPI=4
>>
>> While T is defined in all phases, PMS also says that "pkg_pretend must
>> not write to the filesystem".
>>
>> Is it allowed to write to T or not? Can the specs be clearer if it's
>> allowed?
> 
> sounds like a good reason to use emktemp as that'll utilize /tmp for files 
> when $T is unavailable
> 

That approach would still write to the filesystem. With the current text
the PM is probably allowed to set the sandbox so that writing is
anywhere is denied.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] write to filesystem in pkg_pretend

[justin]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

On 18/06/11 13:18, Petteri Räty wrote:
> On 17.06.2011 20:18, Mike Frysinger wrote:
>> On Friday, June 17, 2011 12:25:21 Torsten Veller wrote:
>>> * justin <jlec@gentoo.org>:
>>>> Now using the new pkg_pretend for EAPI=4
>>>
>>> While T is defined in all phases, PMS also says that "pkg_pretend must
>>> not write to the filesystem".
>>>
>>> Is it allowed to write to T or not? Can the specs be clearer if it's
>>> allowed?
>>
>> sounds like a good reason to use emktemp as that'll utilize /tmp for files 
>> when $T is unavailable
>>
> 
> That approach would still write to the filesystem. With the current text
> the PM is probably allowed to set the sandbox so that writing is
> anywhere is denied.
> 
> Regards,
> Petteri
> 

The reason why it would be beneficial to use is the pkg_pretend phase is
simply that the checks would run at the beginning of a emerge and it
would fail directly instead somewhere in the middle. For a single
package it won't change much but for a huge emerge it changes the things.

But when there is no writing allowed during the pretend phase. then the
only chance is to move it to pkg_setup.

thanks for clarification.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] write to filesystem in pkg_pretend

[Ulrich Mueller]

>>>>> On Sat, 18 Jun 2011, justin  wrote:

> On 18/06/11 13:18, Petteri Räty wrote:
>> That approach would still write to the filesystem. With the current
>> text the PM is probably allowed to set the sandbox so that writing
>> is anywhere is denied.

> The reason why it would be beneficial to use is the pkg_pretend
> phase is simply that the checks would run at the beginning of a
> emerge and it would fail directly instead somewhere in the middle.
> For a single package it won't change much but for a huge emerge it
> changes the things.

> But when there is no writing allowed during the pretend phase. then
> the only chance is to move it to pkg_setup.

I wonder if we could loosen up that requirement in PMS. In Portage
at least, T seems to point to an existing directory in pkg_pretend.
I don't know about the other package managers though.

Ulrich

Re: [gentoo-dev] write to filesystem in pkg_pretend

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

On Sat, 18 Jun 2011 14:18:28 +0200
justin <jlec@gentoo.org> wrote:
> The reason why it would be beneficial to use is the pkg_pretend phase
> is simply that the checks would run at the beginning of a emerge and
> it would fail directly instead somewhere in the middle. For a single
> package it won't change much but for a huge emerge it changes the
> things.

Hang on... What happens if someone doesn't have a fortran compiler
installed, but installs one and then installs a fortran-using package
all as part of the same group of packages? Then your pkg_pretend will
fail incorrectly.

Also, you appear to be assuming that environment variable saving
carries over from pkg_pretend to later phases. It doesn't.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] write to filesystem in pkg_pretend

[justin]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

On 18/06/11 15:08, Ciaran McCreesh wrote:
> On Sat, 18 Jun 2011 14:18:28 +0200
> justin <jlec@gentoo.org> wrote:
>> The reason why it would be beneficial to use is the pkg_pretend phase
>> is simply that the checks would run at the beginning of a emerge and
>> it would fail directly instead somewhere in the middle. For a single
>> package it won't change much but for a huge emerge it changes the
>> things.
> 
> Hang on... What happens if someone doesn't have a fortran compiler
> installed, but installs one and then installs a fortran-using package
> all as part of the same group of packages? Then your pkg_pretend will
> fail incorrectly.

That's a serious reason to go to pkg_Setup, which ends the discusion.
thanks.

> 
> Also, you appear to be assuming that environment variable saving
> carries over from pkg_pretend to later phases. It doesn't.
> 

If I get it correctly the pretend phase is also executed when the
individual packages gets emerged not only when the emerge of multiple
packages is started. But the original intention of everything is that
user can do FC=myFortranCompiler emerge foo. And there the FC will be
preserved for every package.

Thanks justin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] write to filesystem in pkg_pretend

[justin]

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

So here are the last changes. Everything is in pkg_setup now, because of
the dependency problem found by Ciaran.




 eclass/fortran-2.eclass |   28 ++++++----------------------
 1 files changed, 6 insertions(+), 22 deletions(-)

diff --git a/eclass/fortran-2.eclass b/eclass/fortran-2.eclass
index 600d107..3f35197 100644
--- a/eclass/fortran-2.eclass
+++ b/eclass/fortran-2.eclass
@@ -16,7 +16,7 @@
 # and exports the variables FC and F77.
 # Optionally, it checks for extended capabilities based on
 # the variable options selected in the ebuild
-# The only phase functions exported are pkg_pretend and pkg_setup.
+# The only phase function exported is fortran-2_pkg_setup.

 # @ECLASS-VARIABLE: FORTRAN_NEED_OPENMP
 # @DESCRIPTION:
@@ -122,10 +122,10 @@ _die_msg() {
 	die "Currently no working fortran compiler is available"
 }

-# @FUNCTION: fortran-2_pkg_pretend
+# @FUNCTION: fortran-2_pkg_setup
 # @DESCRIPTION:
 # Setup functionallity, checks for a valid fortran compiler and
optionally for its openmp support.
-fortran-2_pkg_pretend() {
+fortran-2_pkg_setup() {
 	local dialect

 	: ${F77:=$(tc-getFC)}
@@ -145,27 +145,11 @@ fortran-2_pkg_pretend() {
 		_fortran-has-openmp || \
 			die "Please install current gcc with USE=openmp or set the FC
variable to a compiler that supports OpenMP"
 	fi
-}
-
-# @FUNCTION: fortran-2_pkg_setup
-# @DESCRIPTION:
-# In EAPI < 4 it calls the compiler check. This behavior is deprecated
-# and will be removed at 01-Okt-2011. Please migrate to EAPI=4.
-#
-# Exports the FC and F77 variable according to the compiler checks.
-fortran-2_pkg_setup() {
-	if has ${EAPI:-0} 0 1 2 3; then
-		ewarn "The support for EAPI=${EAPI} by the fortran-2.eclass"
-		ewarn "will be end at 01-Okt-2011"
-		ewarn "Please migrate your package to EAPI=4"
-		fortran-2_pkg_pretend
-	fi
-	[[ -n ${F77} ]] || export F77=$(tc-getFC)
-	[[ -n ${FC} ]] || export FC=$(tc-getFC)
+	tc-export F77
+	tc-export FC
 }

 case ${EAPI:-0} in
-	1|2|3) EXPORT_FUNCTIONS pkg_setup ;;
-	4) EXPORT_FUNCTIONS pkg_pretend pkg_setup ;;
+	1|2|3|4) EXPORT_FUNCTIONS pkg_setup ;;
 	*) die "EAPI=${EAPI} is not supported" ;;
 esac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] write to filesystem in pkg_pretend

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 109 bytes --]

On Saturday, June 18, 2011 10:55:50 justin wrote:
> +	tc-export F77
> +	tc-export FC

tc-export F77 FC
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Please review fortran-2.eclass next round

[justin]

[-- Attachment #1.1: Type: text/plain, Size: 107 bytes --]

hi,

After some discussion the eclass evolved and is ready for the next round
of discussion.

justin

[-- Attachment #1.2: fortran-2.eclass --]
[-- Type: text/plain, Size: 4742 bytes --]

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# Author Justin Lecher <jlec@gentoo.org>
# Test functions provided by Sebastien Fabbro and Kacper Kowalik

# @ECLASS: fortran-2.eclass
# @MAINTAINER:
# jlec@gentoo.org
# sci@gentoo.org
# @BLURB: Packages, which need a fortran compiler should inherit this eclass.
# @DESCRIPTION:
# If you need a fortran compiler, inherit this eclass. This eclass tests for
# working fortran compilers and exports the variables FC and F77.
# Optional, it checks for openmp capability of the
# current fortran compiler through FORTRAN_NEED_OPENMP=1.
# Only phase function exported is pkg_pretend and pkg_setup.
# Need help? Ask the sci team.

# @ECLASS-VARIABLE: FORTRAN_NEED_OPENMP
# @DESCRIPTION:
# Set FORTRAN_NEED_OPENMP=1 in order to test FC for openmp capabilities
#
# Default is 0

# @ECLASS-VARIABLE: FORTRAN_STANDARD
# @DESCRIPTION:
# Set this, if a special dialect needs to be support. Generally not needed.
#
# Valid settings are any combination of
#
# FORTRAN_STANDARD="77 90 95 2003"
#
# Defaults to FORTRAN_STANDARD="77" which is sufficient for most cases.

inherit toolchain-funcs

DEPEND="virtual/fortran"
RDEPEND="${DEPEND}"

# internal function
#
# FUNCTION: _write_testsuite
# DESCRIPTION: writes fortran test code
_write_testsuite() {
	local filebase=${T}/test-fortran

	# f77 code
	cat <<- EOF > "${filebase}.f"
	       end
	EOF

	# f90/95 code
	cat <<- EOF > "${filebase}.f90"
	end
	EOF

	# f2003 code
	cat <<- EOF > "${filebase}.f03"
	       procedure(), pointer :: p
	       end
	EOF
}

# internal function
#
# FUNCTION: _compile_test
# DESCRIPTION:
# Takes fortran compiler as first argument and dialect as second.
# Checks whether the passed fortran compiler speaks the fortran dialect
_compile_test() {
	local filebase=${T}/test-fortran
	local fcomp=${1}
	local fdia=${2}

	[[ -z ${fcomp} ]] && die "_compile_test() needs at least one argument"

	[[ -f "${filebase}.f${fdia}" ]] || _write_testsuite

	${fcomp} "${filebase}.f${fdia}" -o "${filebase}-f${fdia}" >&/dev/null
	local ret=$?

	rm -f "${filebase}-f${fdia}"
	return ${ret}
}

# internal function
#
# FUNCTION: _fortran-has-openmp
# DESCRIPTION:
# See if the fortran supports OpenMP.
_fortran-has-openmp() {
	local flag
	local filebase=${T}/test-fc-openmp

	cat <<- EOF > "${filebase}.f"
	       call omp_get_num_threads
	       end
	EOF

	for flag in -fopenmp -xopenmp -openmp -mp -omp -qsmp=omp; do
		$(tc-getFC "$@") ${flag} "${filebase}.f" -o "${filebase}" >&/dev/null
		local ret=$?
		(( ${ret} )) || break
	done

	rm -f "${filebase}"*
	return ${ret}
}

# internal
#
# FUNCTION: _die_msg
# DESCRIPTION: Detailed description how to handle fortran support
_die_msg() {
	echo
	eerror "Please install currently selected gcc version with USE=fortran."
	eerror "If you intend to use a different compiler then gfortran, please"
	eerror "set FC variable accordingly and take care that the neccessary"
	eerror "fortran dialects are support."
	echo
	die "Currently no working fortran compiler is available"
}

# @FUNCTION: fortran-2_pkg_pretend
# @DESCRIPTION:
# Setup functionallity, checks for a valid fortran compiler and optionally for its openmp support.
fortran-2_pkg_pretend() {
	local dialect

	[[ -n ${F77} ]] || F77=$(tc-getFC)

	: ${FORTRAN_STANDARD:=77}
	for dialect in ${FORTRAN_STANDARD}; do
		case ${dialect} in
			77) _compile_test $(tc-getF77) || _die_msg ;;
			90|95) _compile_test $(tc-getFC) 90 || _die_msg ;;
			2003) _compile_test $(tc-getFC) 03 || _die_msg ;;
			2008) die "Future" ;;
			*) die "${dialect} is not a Fortran dialect." ;;
		esac
	done

	if [[ ${FORTRAN_NEED_OPENMP} == 1 ]]; then
		_fortran-has-openmp || \
			die "Please install current gcc with USE=openmp or set the FC variable to a compiler that supports OpenMP"
	fi
}

# @FUNCTION: fortran-2_pkg_setup
# @DESCRIPTION:
# In EAPI < 4 it calls the compiler check. This behavior is deprecated
# and will be removed at 01-Sep-2011. Please migrate to EAPI=4.
#
# Exports the FC and F77 variable according to the compiler checks.
fortran-2_pkg_setup() {
	if has ${EAPI:-0} 0 1 2 3; then
		ewarn "The support for EAPI=${EAPI} by the fortran-2.eclass"
		ewarn "will be end at 01-Sep-2011"
		ewarn "Please migrate your package to EAPI=4"
		fortran-2_pkg_pretend
	fi
	[[ -n ${F77} ]] || export F77=$(tc-getFC)
	[[ -n ${FC} ]] || export FC=$(tc-getFC)
}

case "${EAPI:-0}" in
	1|2|3) EXPORT_FUNCTIONS pkg_setup ;;
	4) EXPORT_FUNCTIONS pkg_pretend pkg_setup ;;
	*) die "EAPI=${EAPI} is not supported" ;;
esac

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]

Re: [gentoo-dev] Please review fortran-2.eclass next round

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 3626 bytes --]

> # @ECLASS: fortran-2.eclass

i dont see fortran.eclass.  what's with the "-2" ?

> @BLURB: Packages, which need a fortran compiler should inherit this eclass.

@BLURB: simplify fortran compiler management

>@DESCRIPTION:
> If you need a fortran compiler, inherit this eclass.

If you need a fortran compiler, then you should be inheriting this eclass.

> Optional, it checks for openmp capability of the current fortran compiler
> through FORTRAN_NEED_OPENMP=1.

Optionally, it checks for extended capabilities based on the variable options 
selected in the ebuild.

> Only phase function exported is pkg_pretend and pkg_setup.

The only phase functions exported are pkg_pretend and pkg_setup.

> Need help? Ask the sci team.

seems redundant what with the @MAINTAINER field ...

> # @ECLASS-VARIABLE: FORTRAN_NEED_OPENMP
> # @DESCRIPTION:
> # Set FORTRAN_NEED_OPENMP=1 in order to test FC for openmp capabilities

Set to "1" in order to automatically have the eclass abort if the fortran 
compiler lacks openmp support.

> #
> # Default is 0

have the code list the default and then you don't need this.  simply use:
: ${FORTRAN_NEED_OPENMP:=0}

> # @ECLASS-VARIABLE: FORTRAN_STANDARD
> # @DESCRIPTION:
> # Set this, if a special dialect needs to be support. Generally not needed.

drop the comma and add "ed" to support

> # Valid settings are any combination of
> #
> # FORTRAN_STANDARD="77 90 95 2003"

Valid settings are any combination of: 77 90 95 2003

> # Defaults to FORTRAN_STANDARD="77" which is sufficient for most cases.

same as the openmp code; list the default after the comment:
: ${FORTRAN_STANDARD:=77}

> DEPEND="virtual/fortran"
> RDEPEND="${DEPEND}"

i'm not sure that RDEPEND is correct.  do all fortran compilers additionally 
require the fortran compiler to be available at runtime ?

> # internal function

use the @INTERNAL tag and proper eclass documentation

> local filebase=${T}/test-fortran

there is $(emktemp) ... but this is probably fine ...

> 	[[ -z ${fcomp} ]] && die "_compile_test() needs at least one argument"

probably want: [[ $# -eq 0 ]]

>	[[ -f "${filebase}.f${fdia}" ]] || _write_testsuite

no need to quote with [[...]]

>	[[ -f "${filebase}.f${fdia}" ]] || _write_testsuite
>
>	${fcomp} "${filebase}.f${fdia}" -o "${filebase}-f${fdia}" >&/dev/null
>	local ret=$?
>
>	rm -f "${filebase}-f${fdia}"

seems like you want a local var that is like:
	${filebase}.f${fdia}
and then you write the output to:
	${filebase}.f${fdia}.x
and then you don't need to repeat this logic multiple times ...

>		$(tc-getFC "$@") ${flag} "${filebase}.f" -o "${filebase}" >&/dev/null

tc-getFC could expand into a bit of logic ... probably better to cache the 
result in a local var

>		local ret=$?

local is a command, and is a bit odd to see inside of a for loop.  please 
hoist it up to the top with the "local flag" decl.

>		(( ${ret} )) || break

a little odd syntax, but i guess it works ...

>	eerror "fortran dialects are support."

supported

>	die "Currently no working fortran compiler is available"

"is available" -> "could be located"

>	[[ -n ${F77} ]] || F77=$(tc-getFC)

: ${F77:=$(tc-getFC)}

although i wonder why you're not using tc-getF77 ...

>		ewarn "The support for EAPI=${EAPI} by the fortran-2.eclass"

why ?  it's causing you no real trouble to do so

>	[[ -n ${F77} ]] || export F77=$(tc-getFC)

same comment as before ...

>	[[ -n ${FC} ]] || export FC=$(tc-getFC)

tc-export FC

> case "${EAPI:-0}" in

no need to quote
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Please review fortran-2.eclass next round

[justin]

[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]

Thanks again Mike for an extended review. Some replies on your comments
everything else is directly excepted.

On 17/06/11 05:03, Mike Frysinger wrote:
>> # @ECLASS: fortran-2.eclass
> 
> i dont see fortran.eclass.  what's with the "-2" ?

There was a fortran eclass, which did completely different things. In
order  to not break an ancient package (outside the tree) I decided to
go to the new name, which also underlines the new functionality.

>> DEPEND="virtual/fortran"
>> RDEPEND="${DEPEND}"
> 
> i'm not sure that RDEPEND is correct.  do all fortran compilers additionally 
> require the fortran compiler to be available at runtime ?

I will evaluate this and fix it accordingly. But I see difficulties, if
it is mixed. Best would be to fix that in virtual/fortran

> 
>> # internal function
> 
> use the @INTERNAL tag and proper eclass documentation

I wasn't aware of that. We are lacking any documentation about the
proper documentation for manpages in all eclass writing guides.

>> 		(( ${ret} )) || break
>
> a little odd syntax, but i guess it works ...
>

I don't know any other way how I can jump out of the loop. The complete
things simulates the autoconf behavior.

> 
> although i wonder why you're not using tc-getF77 ...

Because tc-getF77 is only different to tc-getFC if F77 is set. And this
is tested for before.

> 
>> 		ewarn "The support for EAPI=${EAPI} by the fortran-2.eclass"
> 
> why ?  it's causing you no real trouble to do so
> 

The suggestion was to only support EAPI=4. I don't like this completely
as all fortran packages should directly use the eclass in order to make
it smooth for users. The delay should give some time to come up with
stable versions for all fortran packages at EAPI=4, but allow the use in
every ebuild right away.


> -mike

Thank you very much,

justin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Please review fortran-2.eclass next round

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1717 bytes --]

On Friday, June 17, 2011 02:05:59 justin wrote:
> On 17/06/11 05:03, Mike Frysinger wrote:
> >> # @ECLASS: fortran-2.eclass
> > 
> > i dont see fortran.eclass.  what's with the "-2" ?
> 
> There was a fortran eclass, which did completely different things. In
> order  to not break an ancient package (outside the tree) I decided to
> go to the new name, which also underlines the new functionality.

thanks; makes sense

> >> # internal function
> > 
> > use the @INTERNAL tag and proper eclass documentation
> 
> I wasn't aware of that. We are lacking any documentation about the
> proper documentation for manpages in all eclass writing guides.

the syntax is fully documented in the utility that generates it.  see the awk 
in the eclass-manpages filesdir.

> >> 		(( ${ret} )) || break
> > 
> > a little odd syntax, but i guess it works ...
> 
> I don't know any other way how I can jump out of the loop. The complete
> things simulates the autoconf behavior.

i just meant using "(( ${ret} ))" rather than "[[ ${ret} -eq 0 ]]"

> >> 		ewarn "The support for EAPI=${EAPI} by the fortran-2.eclass"
> > 
> > why ?  it's causing you no real trouble to do so
> 
> The suggestion was to only support EAPI=4. I don't like this completely
> as all fortran packages should directly use the eclass in order to make
> it smooth for users. The delay should give some time to come up with
> stable versions for all fortran packages at EAPI=4, but allow the use in
> every ebuild right away.

if you want to keep older EAPI support, and/or it's trivial to do so, then 
you're free to disagree with the suggestion and keep support.  you are the 
maintainer of this after all.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Please review fortran-2.eclass next round

[justin]

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

>> I wasn't aware of that. We are lacking any documentation about the
>> proper documentation for manpages in all eclass writing guides.
> 
> the syntax is fully documented in the utility that generates it.  see the awk 
> in the eclass-manpages filesdir.
> 

This is not a proper way of documentation.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Please review fortran-2.eclass next round

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 585 bytes --]

On Friday, June 17, 2011 02:40:27 justin wrote:
> >> I wasn't aware of that. We are lacking any documentation about the
> >> proper documentation for manpages in all eclass writing guides.
> > 
> > the syntax is fully documented in the utility that generates it.  see the
> > awk in the eclass-manpages filesdir.
> 
> This is not a proper way of documentation.

in your opinion of course.  makes perfect sense to me though to have the 
documentation in the exact same file as the code that implements said 
documentation.  more likely that the two are kept in sync.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Please review fortran-2.eclass next round

[Kacper Kowalik]

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]

W dniu 17.06.2011 05:03, Mike Frysinger pisze:
>> DEPEND="virtual/fortran"
>> > RDEPEND="${DEPEND}"
> i'm not sure that RDEPEND is correct.  do all fortran compilers additionally 
> require the fortran compiler to be available at runtime ?
They require fortran runtime library if they don't link it statically.
Cheers,
Kacper



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 380 bytes --]

Re: [gentoo-dev] Please review fortran-2.eclass next round

[justin]

[-- Attachment #1.1: Type: text/plain, Size: 537 bytes --]

On 17/06/11 11:01, Kacper Kowalik wrote:
> W dniu 17.06.2011 05:03, Mike Frysinger pisze:
>>> DEPEND="virtual/fortran"
>>>> RDEPEND="${DEPEND}"
>> i'm not sure that RDEPEND is correct.  do all fortran compilers additionally 
>> require the fortran compiler to be available at runtime ?
> They require fortran runtime library if they don't link it statically.
> Cheers,
> Kacper
> 
> 
Thanks for clarification. We leave them as RDEPEND as well and handle
any (future) exeption in the virtual.

Here the updated eclass:



[-- Attachment #1.2: fortran-2.eclass --]
[-- Type: text/plain, Size: 4524 bytes --]

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# Author Justin Lecher <jlec@gentoo.org>
# Test functions provided by Sebastien Fabbro and Kacper Kowalik

# @ECLASS: fortran-2.eclass
# @MAINTAINER:
# jlec@gentoo.org
# sci@gentoo.org
# @BLURB: Simplify fortran compiler management
# @DESCRIPTION:
# If you need a fortran compiler, then you should be inheriting this eclass.
# The eclass tests for working fortran compilers
# and exports the variables FC and F77.
# Optionally, it checks for extended capabilities based on
# the variable options selected in the ebuild
# The only phase functions exported are pkg_pretend and pkg_setup.

# @ECLASS-VARIABLE: FORTRAN_NEED_OPENMP
# @DESCRIPTION:
# Set to "1" in order to automatically have the eclass abort if the fortran
# compiler lacks openmp support.
: ${FORTRAN_NEED_OPENMP:=0}

# @ECLASS-VARIABLE: FORTRAN_STANDARD
# @DESCRIPTION:
# Set this, if a special dialect needs to be supported.
# Generally not needed as default is sufficient.
#
# Valid settings are any combination of: 77 90 95 2003
: ${FORTRAN_STANDARD:=77}

inherit toolchain-funcs

DEPEND="virtual/fortran"
RDEPEND="${DEPEND}"

# @FUNCTION: _write_testsuite
# @DESCRIPTION: writes fortran test code
# @INTERNAL
_write_testsuite() {
	local filebase=${T}/test-fortran

	# f77 code
	cat <<- EOF > "${filebase}.f"
	       end
	EOF

	# f90/95 code
	cat <<- EOF > "${filebase}.f90"
	end
	EOF

	# f2003 code
	cat <<- EOF > "${filebase}.f03"
	       procedure(), pointer :: p
	       end
	EOF
}

# @FUNCTION: _compile_test
# @DESCRIPTION:
# Takes fortran compiler as first argument and dialect as second.
# Checks whether the passed fortran compiler speaks the fortran dialect
# @INTERNAL
_compile_test() {
	local filebase=${T}/test-fortran
	local fcomp=${1}
	local fdia=${2}
	local fcode=${filebase}.f${fdia}
	local ret

	[[ $# -eq 0 ]] && die "_compile_test() needs at least one argument"

	[[ -f ${fcode} ]] || _write_testsuite

	${fcomp} "${fcode}" -o "${fcode}.x" >&/dev/null
	ret=$?

	rm -f "${fcode}.x"
	return ${ret}
}

# @FUNCTION: _fortran-has-openmp
# @DESCRIPTION:
# See if the fortran supports OpenMP.
# @INTERNAL
_fortran-has-openmp() {
	local flag
	local filebase=${T}/test-fc-openmp
	local fcode=${filebase}.f
	local ret
	local _fc=$(tc-getFC)

	cat <<- EOF > "${fcode}"
	       call omp_get_num_threads
	       end
	EOF

	for flag in -fopenmp -xopenmp -openmp -mp -omp -qsmp=omp; do
		${_fc} ${flag} "${fcode}" -o "${fcode}.x" >&/dev/null
		ret=$?
		(( ${ret} )) || break
	done

	rm -f "${fcode}.x"
	return ${ret}
}

# @FUNCTION: _die_msg
# @DESCRIPTION: Detailed description how to handle fortran support
# @INTERNAL
_die_msg() {
	echo
	eerror "Please install currently selected gcc version with USE=fortran."
	eerror "If you intend to use a different compiler then gfortran, please"
	eerror "set FC variable accordingly and take care that the neccessary"
	eerror "fortran dialects are support."
	echo
	die "Currently no working fortran compiler is available"
}

# @FUNCTION: fortran-2_pkg_pretend
# @DESCRIPTION:
# Setup functionallity, checks for a valid fortran compiler and optionally for its openmp support.
fortran-2_pkg_pretend() {
	local dialect

	: ${F77:=$(tc-getFC)}

	: ${FORTRAN_STANDARD:=77}
	for dialect in ${FORTRAN_STANDARD}; do
		case ${dialect} in
			77) _compile_test $(tc-getF77) || _die_msg ;;
			90|95) _compile_test $(tc-getFC) 90 || _die_msg ;;
			2003) _compile_test $(tc-getFC) 03 || _die_msg ;;
			2008) die "Future" ;;
			*) die "${dialect} is not a Fortran dialect." ;;
		esac
	done

	if [[ ${FORTRAN_NEED_OPENMP} == 1 ]]; then
		_fortran-has-openmp || \
			die "Please install current gcc with USE=openmp or set the FC variable to a compiler that supports OpenMP"
	fi
}

# @FUNCTION: fortran-2_pkg_setup
# @DESCRIPTION:
# In EAPI < 4 it calls the compiler check. This behavior is deprecated
# and will be removed at 01-Okt-2011. Please migrate to EAPI=4.
#
# Exports the FC and F77 variable according to the compiler checks.
fortran-2_pkg_setup() {
	if has ${EAPI:-0} 0 1 2 3; then
		ewarn "The support for EAPI=${EAPI} by the fortran-2.eclass"
		ewarn "will be end at 01-Okt-2011"
		ewarn "Please migrate your package to EAPI=4"
		fortran-2_pkg_pretend
	fi
	[[ -n ${F77} ]] || export F77=$(tc-getFC)
	[[ -n ${FC} ]] || export FC=$(tc-getFC)
}

case ${EAPI:-0} in
	1|2|3) EXPORT_FUNCTIONS pkg_setup ;;
	4) EXPORT_FUNCTIONS pkg_pretend pkg_setup ;;
	*) die "EAPI=${EAPI} is not supported" ;;
esac

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Please review fortran-2.eclass next round

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 539 bytes --]

On Friday, June 17, 2011 05:01:10 Kacper Kowalik wrote:
> W dniu 17.06.2011 05:03, Mike Frysinger pisze:
> >> DEPEND="virtual/fortran"
> >> 
> >> > RDEPEND="${DEPEND}"
> > 
> > i'm not sure that RDEPEND is correct.  do all fortran compilers
> > additionally require the fortran compiler to be available at runtime ?
> 
> They require fortran runtime library if they don't link it statically.

*if* there is a fortran runtime library in the first place.  gcc provides one, 
but does that mean all fortran compilers do ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Please review fortran-2.eclass next round

[Kacper Kowalik]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

W dniu 17.06.2011 18:41, Mike Frysinger pisze:
> On Friday, June 17, 2011 05:01:10 Kacper Kowalik wrote:
>> W dniu 17.06.2011 05:03, Mike Frysinger pisze:
>>>> DEPEND="virtual/fortran"
>>>>
>>>>> RDEPEND="${DEPEND}"
>>>
>>> i'm not sure that RDEPEND is correct.  do all fortran compilers
>>> additionally require the fortran compiler to be available at runtime ?
>>
>> They require fortran runtime library if they don't link it statically.
> 
> *if* there is a fortran runtime library in the first place.  gcc provides one, 
> but does that mean all fortran compilers do ?

At least all that I've used have it. Gcc, path64/open64/ekopath-bin,
solstudio use shared lib. Pgi by default links statically, but have
shared too. Ifort has only static, but has "ugliness" called Portability
Library, which can be linked dynamically:

xarth@aiur:~$ ifort -fpscomp nolibs unlink.F90 -lifport
xarth@aiur:~$ ldd a.out | grep ifport
    libifport.so.5 =>
/opt/intel/Compiler/11.1/072/lib/intel64/libifport.so.5 (0x00007f0e05968000)

It *really* makes things easier if virtual/fortran is in RDEPEND. Is it
serious obstacle?
Cheers,
Kacper
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAk37n1oACgkQIiMqcbOVdxTt+AP7BCeC8Aru8otXmquDy1RcAg8j
Cue952ty2FBn9R+O8P8p7H+FckP/qBcXIuSGdSq1tFR/0HNDlYjwZDIHliY/tUkm
RQV4qY5nMp11yemI/VXnwFXZ1qwjpIoUypj2e3JnjozV3hfSCBdm3FQQYhi0ROls
2ohZThxgrEL1Noq844A=
=ISqo
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Please review fortran-2.eclass next round

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 889 bytes --]

On Friday, June 17, 2011 14:39:22 Kacper Kowalik wrote:
> W dniu 17.06.2011 18:41, Mike Frysinger pisze:
> > On Friday, June 17, 2011 05:01:10 Kacper Kowalik wrote:
> >> W dniu 17.06.2011 05:03, Mike Frysinger pisze:
> >>>> DEPEND="virtual/fortran"
> >>>> 
> >>>>> RDEPEND="${DEPEND}"
> >>> 
> >>> i'm not sure that RDEPEND is correct.  do all fortran compilers
> >>> additionally require the fortran compiler to be available at runtime ?
> >> 
> >> They require fortran runtime library if they don't link it statically.
> > 
> > *if* there is a fortran runtime library in the first place.  gcc provides
> > one, but does that mean all fortran compilers do ?
> 
> It *really* makes things easier if virtual/fortran is in RDEPEND. Is it
> serious obstacle?

i didnt say it was an obstacle.  i asked if it's actually correct.  atm, it 
would seem it is required.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]