On 2020-03-18 17:42, Gilles Filippini wrote:
Gilles Filippini a écrit le 17/03/2020 à 17:59 :
As I understand it now, this is do-able if and only if there is a way
to
add a slave to an existing alternative. But I can't find such a way.
Any
idea?
Looks like you got an idea before I did on how to do it before I do :)
I'm almost done, but there is a corner case we have to accept. When:
1- Default MPI toolchain for the arch is installed
2- The selected 'mpi' alternative points to this default MPI toolchain
3- The libhdf5-<mpi>-dev flavor for this default toolchain is NOT
installed
4- Another libhdf5-<mpi>-dev flavor is installed
Then the hdf5-mpi.pc slave points to nothing until one of these
conditions is satisfied:
* The libhdf5-<mpi>-dev flavor for this default toolchain is installed
or
* The 'mpi' alternative points to the MPI flavor corresponding to the
installed libhdf5-<mpi>-dev.
Do we agree?
That sounds perfectly reasonable.
That scenario is odd, and very specific. It means the system
administrator has deliberately chosen to not install the preferred
hdf5-<preferred_mpi> and to install the non-preferred
hdf5-<nonpreferred_mpi> instead ("preferred" in the mpi alternatives
sense).
In those conditions it's reasonable that users of that system should
need to be specific about which hdf5-mpi they're using, invoking
"pkg-config --cflags hdf5-<nonpreferred_mpi>" rather than "pkg-config
--cflags hdf5-mpi". Their system administrator can still configure
their preferred hdf5 so they can use "pkg-config --cflags hdf5" to
access their hdf5-<nonpreferred_mpi>, if they want.
Thanks for sorting through the alternatives logic.
Drew
