[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild

[Donnie Berkholz]

On 02:10 Thu 13 Dec     , Justin Bronder (jsbronder) wrote:
> 1.1                  sys-cluster/openmpi/openmpi-1.2.4.ebuild
> 
> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1&view=markup
> plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1&content-type=text/plain

> 	if [[ -n "${FORTRANC}" ]]; then

This should be 'if use fortran' like the one earlier, to make it clear 
what you're really testing: whether it's a fortran-enabled build.

> 		if [[ "${FORTRANC}" = "g77" ]]; then
> 			myconf="${myconf} --disable-mpi-f90"
> 		elif [[ "${FORTRANC}" = "gfortran" ]]; then
> 			# Because that's just a pain in the butt.
> 			myconf="${myconf} --with-wrapper-fflags=-I/usr/include"
> 		fi
> 	else
> 		myconf="${myconf}
> 			--disable-mpi-f90
> 			--disable-mpi-f77"
> 	fi
> 
> 	econf ${myconf} \
> 		$(use_enable !nocxx mpi-cxx) \
> 		$(use_enable romio romio-io) \
> 		$(use_enable smp smp-locks) \
> 		$(use_enable heterogeneous heterogeneous) \

You don't need the second argument, it's identical to the first if not 
present.

> 		$(use_with pbs tm /usr/$(get_libdir)/pbs) \
> 		$(use_with slurm) \
> 		$(use_enable ipv6) \
> 	|| die "econf failed"
> 
> 	emake  || die "emake failed"
> }
> 
> src_install () {
> 	make DESTDIR="${D}" install || die "make install failed"
> 	dodoc README AUTHORS NEWS VERSION
> }

Does emake work?

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild

[Matthias Langer]

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


> On 02:10 Thu 13 Dec     , Justin Bronder (jsbronder) wrote:
> > 1.1                  sys-cluster/openmpi/openmpi-1.2.4.ebuild
> > 
> > file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1&view=markup
> > plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1&content-type=text/plain

Why have you removed the "ifc" USE flag (as well as a few others), that
was present in the ebuilds that can still be found at bug 166787?

Matthias

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild

[Sébastien Fabbro]

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

On 14/12/07 10:24, Matthias Langer wrote:
>> On 02:10 Thu 13 Dec     , Justin Bronder (jsbronder) wrote:
>>> 1.1                  sys-cluster/openmpi/openmpi-1.2.4.ebuild
>>>
>>> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1&view=markup
>>> plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1&content-type=text/plain
> 
> Why have you removed the "ifc" USE flag (as well as a few others), that
> was present in the ebuilds that can still be found at bug 166787?

For icc and  f90-typesafe, I advised him to do so on #gentoo-science.

ifc/icc use flags should be avoided (see bug #97929).
Disabling f90-typesafe did not make much sense as a use flag once you
have the fortran one enabled, but why --with-mpi-f90-size=medium"
and "--with-f90-max-array-dim=4" disappeared I don't know.

For the gm and gx flags, I don't know, and there is still a nocxx one.

- --
Sébastien
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYnNi1ycZbhPLE2ARAq10AKCtnkZMWBkws7lD90bNAziSc4XJ3wCgiDD4
T5oOmc65RMnjswIBlHHh3Yg=
=VcUX
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild

[Matthias Langer]

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


On Fri, 2007-12-14 at 12:13 +0000, Sébastien Fabbro wrote: 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 14/12/07 10:24, Matthias Langer wrote:
> >> On 02:10 Thu 13 Dec     , Justin Bronder (jsbronder) wrote:
> >>> 1.1                  sys-cluster/openmpi/openmpi-1.2.4.ebuild
> >>>
> >>> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1&view=markup
> >>> plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1&content-type=text/plain
> > 
> > Why have you removed the "ifc" USE flag (as well as a few others), that
> > was present in the ebuilds that can still be found at bug 166787?
> 
> For icc and  f90-typesafe, I advised him to do so on #gentoo-science.

Well, too bad that gfortran generates code that is often not even half
as fast as the code generated by ifc. Thus, there is a *very valid*
reason to prefer icc over gfortran when it comes to performance critical
software, which programs that use MPI almost always are. However, the
fortran eclass prefers gfortran over ifc even if both are installed
(which is fine by me as long as it can be overridden) and the
fortran-compiler-wrapper "mpif90/opal_wrapper" (which is a binary for
some reason) wrapps gfortran then.

For sure, something like
F77="ifort" FC="ifort" FFLAGS="-O3 -xO" emerge -av openmpi
still does the trick, but if i want that "f90-typesave" stuff back, this
line would have to be certainly a bit longer...

Maybe someone can explain to me what positive side effects the removal
of the ifc USE flag has - and why this flag is generally discouraged.

> 
> ifc/icc use flags should be avoided (see bug #97929).
> Disabling f90-typesafe did not make much sense as a use flag once you
> have the fortran one enabled, but why --with-mpi-f90-size=medium"
> and "--with-f90-max-array-dim=4" disappeared I don't know.

The reason it disappeared is that it makes gfortran horribly slow when
compiling against mpi. This is not the case with ifc, and therefore the
old ebuild in bugzilla emitted a bold warning when emerging with
USE="-ifc f90-typesafe" but kept quiet if USE="ifc f90-typesave". Thus
it *did make sense* to control it with a USE flag, at least with the
"ifc" USE flag being around also.

> For the gm and gx flags, I don't know, and there is still a nocxx one.

I'm not qualified to talk about these flags as I've never used them.

Matthias

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

[gentoo-dev] Re: gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild

[Justin Bronder]

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

On 14/12/07 12:13 +0000, Sébastien Fabbro wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 14/12/07 10:24, Matthias Langer wrote:
> >> On 02:10 Thu 13 Dec     , Justin Bronder (jsbronder) wrote:
> >>> 1.1                  sys-cluster/openmpi/openmpi-1.2.4.ebuild
> >>>
> >>> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1&view=markup
> >>> plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1&content-type=text/plain
> > 
> > Why have you removed the "ifc" USE flag (as well as a few others), that
> > was present in the ebuilds that can still be found at bug 166787?
> 
> For icc and  f90-typesafe, I advised him to do so on #gentoo-science.
> 
> ifc/icc use flags should be avoided (see bug #97929).
> Disabling f90-typesafe did not make much sense as a use flag once you
> have the fortran one enabled, but why --with-mpi-f90-size=medium"
> and "--with-f90-max-array-dim=4" disappeared I don't know.

For the first, chalk this up to my own inexperience with fortran.  Is this
going to be common enough to justify a USE flag?  Would it be better to just
enable it by default when gfortran is not being used given that is slows
compilation down significantly?

In the case of the latter, that is the default when no options are passed.

> For the gm and gx flags, I don't know, and there is still a nocxx one.

There are no ebuilds for the above packages.  I submitted them at the same
time I commented on the openmpi bug, but no longer have access to that
hardware.  If someone does and would be willing to work with me on finishing
up those ebuilds, please contact me.

-- 
Justin Bronder

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild

[Sébastien Fabbro]

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

On 14/12/07 14:12, Matthias Langer wrote:

> F77="ifort" FC="ifort" FFLAGS="-O3 -xO" emerge -av openmpi

This how it should be. To make it automatically reproducible, specify
environment variables in the configuration files.

> Maybe someone can explain to me what positive side effects the removal
> of the ifc USE flag has - and why this flag is generally discouraged.

Positive side effect: avoid cluttering the tree. Why icc/ifc are
discouraged: you can always try to compile every C/C++ package with
CC=icc and fortran packages with F77=ifort or FC=ifort. Packages which
do specify more options with e.g. --enable-icc and friends can be easily
worked out with the toolchain-funcs and fortran eclass, and most of the
time they do nothing more than specify the environment variables.

If we allow icc/ifc flags, at some point, we could allow a whole bunch
of other compiler flags such as "sunstudio". New keywords for compilers
could be a better idea, but I doubt we have the human resources to test
them.

> The reason it disappeared is that it makes gfortran horribly slow when
> compiling against mpi. This is not the case with ifc, and therefore the
> old ebuild in bugzilla emitted a bold warning when emerging with
> USE="-ifc f90-typesafe" but kept quiet if USE="ifc f90-typesave". Thus
> it *did make sense* to control it with a USE flag, at least with the
> "ifc" USE flag being around also.

If the f90-typesafe options always improve compilation time with
gfortran only,  why not using something like this (modified from the
openmpi bump bug):

if use fortran; then
	case ${FORTRANC} in
		g77) myconf="${myconf} --disable-mpi-f90" ;;
		gfortran) myconf="${myconf} --with-mpi-f90-size=medium" 				
myconf="${myconf} --with-f90-max-array-dim=4" 				  ;;
		if*) myconf="${myconf} blah" ;;
		*) die "unsupported fortran compiler: ${FORTRANC}"
	esac
else
	myconf="${myconf} --disable-mpi-f90 --disable-mpi-f77"
fi

Let the ebuild make reasonable choices instead of making a user trying
to find out about undocumented use flags.

- --
Sébastien
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYqxv1ycZbhPLE2ARAlRRAJ9BySHhbxAzLOgJdG4I2L3RpCPPNwCgi8aF
v3OgmxW4UZj1Gqf7Pg2vBWE=
=vYF+
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild

[Matthias Langer]

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


On Fri, 2007-12-14 at 16:16 +0000, Sébastien Fabbro wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 14/12/07 14:12, Matthias Langer wrote:
> 
> > F77="ifort" FC="ifort" FFLAGS="-O3 -xO" emerge -av openmpi
> 
> This how it should be. To make it automatically reproducible, specify
> environment variables in the configuration files.

Hmm, i know this isn't a support list, but as it fits quite well: can
you tell me what configuration files I have to look for?

> 
> > Maybe someone can explain to me what positive side effects the removal
> > of the ifc USE flag has - and why this flag is generally discouraged.
> 
> Positive side effect: avoid cluttering the tree. Why icc/ifc are
> discouraged: you can always try to compile every C/C++ package with
> CC=icc and fortran packages with F77=ifort or FC=ifort. Packages which
> do specify more options with e.g. --enable-icc and friends can be easily
> worked out with the toolchain-funcs and fortran eclass, and most of the
> time they do nothing more than specify the environment variables.
> 
> If we allow icc/ifc flags, at some point, we could allow a whole bunch
> of other compiler flags such as "sunstudio". New keywords for compilers
> could be a better idea, but I doubt we have the human resources to test
> them.

Well, I basically agree. However, it should be noted that fortran cannot
be compared with C/C++. The latter are the languages no gentoo box can
live without, while fortran is a rather exotic kind of beast, that for
mostly historical reasons, is still used in scientific computing.

Last but not least, ifc is in the tree, while "sunstudio" is not...

To cut a long story short: I'm not completely happy with your reasoning,
but you convinced me nonetheless ;-).

> 
> > The reason it disappeared is that it makes gfortran horribly slow when
> > compiling against mpi. This is not the case with ifc, and therefore the
> > old ebuild in bugzilla emitted a bold warning when emerging with
> > USE="-ifc f90-typesafe" but kept quiet if USE="ifc f90-typesave". Thus
> > it *did make sense* to control it with a USE flag, at least with the
> > "ifc" USE flag being around also.
> 
> If the f90-typesafe options always improve compilation time with
> gfortran only,  why not using something like this (modified from the
> openmpi bump bug):

To be exact, "f90-typesafe" slows down gfortran horribly, while ifc
seems to run as fast as normally with it...

> 
> if use fortran; then
> 	case ${FORTRANC} in
> 		g77) myconf="${myconf} --disable-mpi-f90" ;;
> 		gfortran) myconf="${myconf} --with-mpi-f90-size=medium" 				
> myconf="${myconf} --with-f90-max-array-dim=4" 				  ;;
> 		if*) myconf="${myconf} blah" ;;
> 		*) die "unsupported fortran compiler: ${FORTRANC}"
> 	esac
> else
> 	myconf="${myconf} --disable-mpi-f90 --disable-mpi-f77"
> fi
> 

Well, openmpi-1.2.4-r1 has just been commited by jsbronder and contains
code like this...

Matthias 

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild

[Sébastien Fabbro]

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

Matthias Langer wrote:
> On Fri, 2007-12-14 at 16:16 +0000, Sébastien Fabbro wrote:
>>> F77="ifort" FC="ifort" FFLAGS="-O3 -xO" emerge -av openmpi
>> This how it should be. To make it automatically reproducible, specify
>> environment variables in the configuration files.
> 
> Hmm, i know this isn't a support list, but as it fits quite well: can
> you tell me what configuration files I have to look for?

At some point, one possibility was to create a
/etc/portage/env/<cat>/<package> file with your own set of environment
variables in it. But I have not checked lately if we can still do this.

- --
Sébastien
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYt7j1ycZbhPLE2ARAj4YAKCl2ONWLpnEoE71ntWfUlTTh8kmqwCgjQXV
o9lmFEUHuZpVofae23MeL3M=
=Sd/I
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild

[Duncan]

Sébastien Fabbro <bicatali@gentoo.org> posted 4762DEE3.6060604@gentoo.org,
excerpted below, on  Fri, 14 Dec 2007 19:52:03 +0000:

>> Hmm, i know this isn't a support list, but as it fits quite well: can
>> you tell me what configuration files I have to look for?
> 
> At some point, one possibility was to create a
> /etc/portage/env/<cat>/<package> file with your own set of environment
> variables in it. But I have not checked lately if we can still do this.

Should still work, AFAIK (has been here on ~portage), but is portage 
(package manager) specific and then only works on the bash side, not the 
python side, so it won't always work as intended for stuff like features.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list