The total amount of time I've spent getting hwloc "embeddable" has been fairly large. Most recently, I've spent almost the full past 2 days making hwloc embeddable in Open MPI. I'm wondering -- is it worth it?
What's fueling this is that over the past 2-3 months, I've gotten emails from various BSD maintainers and from RedHat saying that they *don't* want to use the PLPA/libltdl/whatever embedded in Open MPI -- they want to link against their system-installed version. Which makes perfect sense from their point of view and quite reasonable of them to ask me to support. The obvious thing for Open MPI to do is to provide a configure switch that allows selecting to use the embedded version or an external one (the same exact situation will occur with hwloc; this is why I bring it up). But to use an external PLPA/libltdl/whatever, OMPI's configure would just call their configure -- no m4-isms would be involved, nor would any symbol shifting occur. So this would make 2 different code paths through the configure/build system -- one that uses m4 and one that invokes another configure script. So I find myself in the uncomfortable position of asking: is all this m4 embedding stuff worth it? Bear with me while I think out loud... + = PRO: a good thing - = CON: a bad thing Embedding gives us two main things: 1. "Seamless" configure magic + The outer configure can slurp in the relevant m4 from hwloc and call it directly (vs. hwloc's configure repeating a bunch of tests [e.g., look for $CC]) - It's not entirely seamless; the outer configure MUST to call AC_USE_EXTENSIONS (etc.) very early on, etc. - It is a ton of development work (for hwloc) to make this work + 95% of this ton of work is already done - ...but it may be a non-trivial amount of work to maintain (this is an unknown quantity) 2. Symbol shifting (hwloc_foo -> my_prefix_hwloc_foo) + Prevents clashes when a package needs a specific hwloc version (E.g., OMPI needs hwloc vX.Y, system has vA.B) + Allows multiple layers in the same app to link against different hwloc versions - Requires upkeep of include/hwloc/rename.h I think the symbol shifting is genuinely useful, despite the annoyance of maintaining rename.h. I'm questioning how useful the m4 embedding is, particularly if OMPI -- and any other distro-supplied software -- is going to have to support compiling and linking against external hwloc instances. I'm wondering if I could accomplish everything I need for OMPI by simply invoking $path_to_hwloc/configure with the existing hwloc configure switches: --enable-embedding-mode: only build libhwloc_embedded.la (no utils, etc.) and don't install *anything* --with-hwloc-symbol-prefix=<foo>: symbol shift all hwloc types and functions I almost wrote "public" types and functions -- but if compiler visibility functionality isn't available, then we need to shift all private-but-not-static symbols, too (I added a chunk to rename.h this afternoon for that). There probably isn't much I would remove from the configure stuff at this point if we gave up the m4-embedding capability. But there probably are a few things that I might simplify (i.e., they were done the way they were done specifically to enable embedding the m4 stuff). So the net "win" of not supporting m4 embedding might be a little simplification and a zero maintenance effort over time -- vs. keeping what is done and maintaining it over time. Thoughts? -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
