-
Notifications
You must be signed in to change notification settings - Fork 902
v2.1.x: --with-hwloc=external fix #3067
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v2.1.x: --with-hwloc=external fix #3067
Conversation
5cf9cd8
to
ea5184f
Compare
ea5184f
to
565e5b5
Compare
I updated this PR (and rebased it, just for good measure) to include a cherry-pick of b8dfd49, which fixes a regression introduced by one of the commits in this PR (i.e., one of the commits in this PR breaks the ability to run I could have just updated the offending commit in this PR, but then the commit wouldn't be a strict cherry-pick from master. Instead, I left the original commit, and just added an additional cherry-pick from master that fixes the issue. |
Frameworks are usually required to have a framework/framework.h file. However, this is sometimes problematic (see the hwloc use case/problem description, below). This commit allows frameworks to have an "autogen.options" file (i.e., project/mca/framework/autogen.options) that specifies things that autogen needs to know about the framework. Currently, the only option recognized in autogen.options is "framework_header", which allows a framework to specify that its header file is named something other than "framework.h" (the framework header file must still be in the project/mca/framework directory; it simply may be named something other than framework.h). More options may be introduced over time. The use case that motivated this is the hwloc framework (open-mpi#2616). Per MCA framework rules, the hwloc framework is required to have an opal/mca/hwloc/hwloc.h file. However, the hwloc library itself *also* has an hwloc.h file. This causes a problem when configuring Open MPI with --with-hwloc=external (meaning: do not use the hwloc embedded within the Open MPI source code tree -- instead, use an hwloc installation from outside the Open MPI source code tree). Specifically, when in the opal/mca/hwloc directory, the presence of "-I." in DEFAULT_INCLUDES (put there by Automake) causes a confusion between the hwloc.h in opal/mca/hwloc/hwloc.h and the system-installed hwloc.h. Chaos ensues (see the GitHub issue for more detail). The solution is to rename the opal/mca/hwloc/hwloc.h to something else (e.g., hwloc-internal.h), and extend autogen.pl to allow frameworks to have an alternate name for their framework header file. This commit introduces the autogen.pl mechanism to allow the alternate header file name. A follow-on commit will effect this change in the hwloc framework (and update all the places in the code base to use the new filename). Signed-off-by: Jeff Squyres <[email protected]> (cherry picked from commit a065b9b)
Per a prior commit, the presence of "hwloc.h" can cause ambiguity when using --with-hwloc=external (i.e., whether to include opal/mca/hwloc/hwloc.h or whether to include the system-installed hwloc.h). This commit: 1. Renames opal/mca/hwloc/hwloc.h to hwloc-internal.h. 2. Adds opal/mca/hwloc/autogen.options to tell autogen.pl to expect to find hwloc-internal.h (instead of hwloc.h) in opal/mca/hwloc. 3. s@opal/mca/hwloc/hwloc.h@opal/mca/hwloc/hwloc-internal.h@g in the rest of the code base. Thanks to Orion Poplawski (@opoplawski) for reporting the issue. Signed-off-by: Jeff Squyres <[email protected]> (cherry picked from commit fec519a)
Commit fec519a broke the ability to run autogen.pl in a distribution tarball. This commit restores that ability by also distributing opal/mca/hwloc/autogen.options in the tarball. Skipping CI because CI does not test this functionality: [skip ci] bot:notest Signed-off-by: Jeff Squyres <[email protected]> (cherry picked from commit b8dfd49)
565e5b5
to
d0b915b
Compare
Fixes #2616 for v2.1.x. Thanks to @opoplawski for reporting.
Set for v2.1.1 release, since the v2.1.0 workaround is "good enough" for the initial release, and we're trying to get v2.1.0 out the door.