Hi, a few questions about configuring in context of packaging v5.x:
1. The top-level ./ompi/configure offers these args as a means to not
use the bundled dependencies:
--with-pmix=DIR
--with-ucx=DIR
--with-ofi=DIR
but not --with-prrte=DIR
Is there an intention to support building against an external PRRTE, or
is PRRTE special and such an option will never be offered? Would you
want a PR for this?
If external PRRTE will be supported, then the following (2) and (3)
don't matter as much, at least for packaging recipes, since those
are issues only with nested deps, and there would be a way to not
rely on nested deps at all.
2. The top-level ./ompi/configure forwards its own args to
the ./configure scripts in nested directories, e.g.
3rd-party/prrte/configure. But, the top-level generates a
warning about unrecognized args destined for nested scripts:
configure: WARNING: unrecognized options: --with-alps
This is not fatal, but it generates noise and obscures valid
warnings about mistyped args. Also, Gentoo portage QA validator picks
this up as a package recipe bug.
So, is the right fix to add something like this? (PR?)
./configure --forward=prrte,--with-alps
This would also force a note n the top-level --help to point out to the
user that there are lots more options in the nested scripts, and to go
read the respective --help. Would reduce confusion when moving from v4
-> v5 with disappearing options: some got removed but some only moved.
3. The top-level ./ompi/autogen.pl does NOT forward any args
to nested ./autogen.{pl,sh}. So,
./autogen.pl --include routed-direct
does not have the intuitive effect (has no effect), because
./3rd-party/prrte/autogen.pl doesn't see that arg.
Forwarding all args unconditionally, like with ./configure, is not an
option since the nested ./autogen.pl fails on unrecognized args. But
forwarding --include,--exclude might be an option -- is that desirable,
which other args shoudl be forwarded too? or, would a
--forward=depname,--arg be better here too?
_______________________________________________
ompi-packagers mailing list
ompi-packagers@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/ompi-packagers
