Our original thought was to not have an external PRRTE, but we have since come
around on that thinking as we are now seeing PRRTE itself being distributed. We
would welcome a PR to add that option if you have time - otherwise, we'll get
to it prior to v5 release.
Thanks!
Ralph
> On Dec 2, 2020, at 4:06 PM, Alexei Colin <aco...@isi.edu> wrote:
>
> 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
_______________________________________________
ompi-packagers mailing list
ompi-packagers@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/ompi-packagers
