FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-15-2011, 09:32 PM
justin
 
Default Please review fortran-2.eclass next round

hi,

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

justin
# 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
 
Old 06-17-2011, 03:03 AM
Mike Frysinger
 
Default Please review fortran-2.eclass next round

> # @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
 
Old 06-17-2011, 06:05 AM
justin
 
Default Please review fortran-2.eclass next round

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
 
Old 06-17-2011, 06:31 AM
Mike Frysinger
 
Default Please review fortran-2.eclass next round

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
 
Old 06-17-2011, 06:40 AM
justin
 
Default Please review fortran-2.eclass next round

>> 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.
 
Old 06-17-2011, 07:13 AM
Mike Frysinger
 
Default Please review fortran-2.eclass next round

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
 
Old 06-17-2011, 09:01 AM
Kacper Kowalik
 
Default Please review fortran-2.eclass next round

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
 
Old 06-17-2011, 10:32 AM
justin
 
Default Please review fortran-2.eclass next round

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:


# 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
 
Old 06-17-2011, 04:41 PM
Mike Frysinger
 
Default Please review fortran-2.eclass next round

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
 
Old 06-17-2011, 06:39 PM
Kacper Kowalik
 
Default Please review fortran-2.eclass next round

-----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+AP7BCeC8Aru8o tXmquDy1RcAg8j
Cue952ty2FBn9R+O8P8p7H+FckP/qBcXIuSGdSq1tFR/0HNDlYjwZDIHliY/tUkm
RQV4qY5nMp11yemI/VXnwFXZ1qwjpIoUypj2e3JnjozV3hfSCBdm3FQQYhi0ROls
2ohZThxgrEL1Noq844A=
=ISqo
-----END PGP SIGNATURE-----
 

Thread Tools




All times are GMT. The time now is 04:34 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org