virtual/mpi-1.0 neglects the use flags of it's managed packages. Hence, when writing an ebuild dependending on this virtual and needing, i.e., an mpi c++ compiler wrapper, you can't set a dependency like "virtual/mpi[cxx]", because "cxx" is not in the "IUSE" flag list of virtual/mpi, in turn because emerging the package would fail for this reason. For virtual packages, I propose to get the IUSE enumeration automatically collected by some portage means, as maintaining the use flag list manually is tedious and error-prone. In this example, you even get a "cxx" use flag, and additionally a "nocxx" use flag, inconsistently describing the same feature. The use flag list manually collected from all packages managed by virtual/mpi-1.0 is this: crypt cxx debug doc elibc_FreeBSD examples fast fortran heterogeneous ipv6 mpe mpe-sdk mpi-threads nocxx pbs pvfs2 romio threads xmpi equery use output for openmpi, mpich2, lam-mpi, mpich: [ Searching for packages matching sys-cluster/openmpi... ] [ Found these USE variables for sys-cluster/openmpi-1.2.8 ] U I - - debug : Enable extra debug codepaths, like asserts and extra output. - - fortran : Adds support for fortran (formerly f77) - - heterogeneous : Enable features required for heterogeneous platform support - - ipv6 : Adds support for IP version 6 - - mpi-threads : Enable MPI_THREAD_MULTIPLE - - nocxx : Disable support for C++ - - pbs : Add support for the Portable Batch System (PBS) - - romio : Build the ROMIO MPI-IO component - - threads : Adds threads support for various packages. Usually pthreads [ Searching for packages matching sys-cluster/mpich2... ] [ Found these USE variables for sys-cluster/mpich2-1.0.6 ] U I + + crypt : Add support for encryption -- using mcrypt or gpg where applicable - - cxx : Builds support for C++ (bindings, extra libraries, code gen, ...) - - debug : Enable extra debug codepaths, like asserts and extra output. - - doc : Adds extra documentation (API, Javadoc, etc) - - elibc_FreeBSD : <unknown> - - fast : Enabling fast turns off error checking and timing collection - - fortran : Adds support for fortran (formerly f77) - - mpe : Add mpe support - - mpe-sdk : Include additional SDK support, jar files - - pvfs2 : Add pvfs2 support - - threads : Adds threads support for various packages. Usually pthreads [ Searching for packages matching sys-cluster/lam-mpi... ] [ Found these USE variables for sys-cluster/lam-mpi-7.1.4 ] U I + + crypt : Add support for encryption -- using mcrypt or gpg where applicable - - debug : Enable extra debug codepaths, like asserts and extra output. - - examples : Install examples, usually source code - - fortran : Adds support for fortran (formerly f77) - - pbs : Add support for the Portable Batch System (PBS) - - romio : Enable romio, a high-performance portable MPI-IO implementation - - xmpi : Build support for the external XMPI debugging GUI [ Searching for packages matching sys-cluster/mpich... ] [ Found these USE variables for sys-cluster/mpich-1.2.7_p1 ] U I + + crypt : Add support for encryption -- using mcrypt or gpg where applicable - - doc : Adds extra documentation (API, Javadoc, etc) Reproducible: Always Steps to Reproduce: 1. emerge mpi[cxx] (or USE=cxx emerge mpi)
The "cxx" versus "nocxx" isuue is a global inconsistency, as "/usr/portage/profiles/use.desc" contains the following two lines: cxx - Builds support for C++ (bindings, extra libraries, code generation, ...) nocxx - Disable support for C++ (DON'T USE THIS UNLESS YOU KNOW WHAT YOU'RE DOING)
Looks like a dirty hack to me, but fair enough...
(In reply to comment #1) > The "cxx" versus "nocxx" isuue is a global inconsistency, as This will be fixed when we get default USE flags in EAPI=1. As for pushing all of the USE flags into virtual/mpi, I really don't think that makes sense as there are far too many differences. I'm willing to accept that cxx/nocxx should be in there, but that's going to have to wait on EAPI=2 or mpi.eclass (from the science overlay) getting updated and accepted. If you can make the case for anything aside from c++ and fortran support, please do.
(In reply to comment #3) > If you can make the case for anything aside from c++ and fortran support, > please do. Specifically, threads and crypt. And generally, perhaps repoman alike tools could check IUSE against the intersection of the set of use flags listed by all depending ebuilds before committing?
(In reply to comment #4) > (In reply to comment #3) > > If you can make the case for anything aside from c++ and fortran support, > > please do. > > Specifically, threads and crypt. And generally, perhaps repoman alike tools > could check IUSE against the intersection of the set of use flags listed by all > depending ebuilds before committing? > None of the stable versions of the MPI implementations have IUSE=crypt and I don't really see a use case for threads (unless you mean mpi-threads which lam-mpi doesn't support and the other two still consider it experimental).
