FWIW: what we do in PMIx (where we also have some overlapping options) is to add in OMPI a new --enable-pmix-foo option and then have the configury in the corresponding OMPI component convert it to use inside of the embedded PMIx itself. It isn’t a big deal - just have to do a little code to save the OMPI settings where they overlap, reset those, and then check for the pmix-specific values to re-enable those that are specified.
Frankly, I prefer that to modifying the non-embedded options - after all, we hope to remove the embedded versions in the near future anyway. > On Dec 20, 2017, at 1:45 PM, Brice Goglin <brice.gog...@inria.fr> wrote: > > Le 20/12/2017 à 22:01, Howard Pritchard a écrit : >> I can think of several ways to fix it. Easiest would be to modify the >> opal/mca/hwloc/hwloc2a/configure.m4 >> to not set --enable-cuda if --with-cuda is evaluated to something other than >> yes. >> >> Optionally, I could fix the hwloc configury to use a --with-cuda argument >> rather than an --enable-cuda configury argument. Would >> such a configury argument change be traumatic for the hwloc community? >> I think it would be weird to have both an --enable-cuda and a --with-cuda >> configury argument for hwloc. >> > > Hello > > hwloc currently only has --enable-foo configure options, but very few > --with-foo. We rely on pkg-config and variables for setting dependency paths. > > OMPI seems to use --enable for enabling features, and --with for enabling > dependencies and setting dependency paths. If that's the official recommended > way to choose between --enable and --with, maybe hwloc should just replace > many --enable-foo with --with-foo ? But I tend to think we should support > both to ease the transition? > > Brice > > _______________________________________________ > devel mailing list > devel@lists.open-mpi.org > https://lists.open-mpi.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/devel