Add embedding capabilies

[ompiteam]

PLPA is "fully embeddable" in larger software projects, meaning:

• Relevant m4 is available in a standalone file that is m4_include'able.
• Specific m4 macros are exported in this file that can be called in a higher-level file (e.g., configure.ac).
• When building in an "embedded" mode, only the library is made (as an LT convenience library); nothing is installed.
• Prefix name shifting is available for all public symbols.

This capability needs to be brought to hwloc before it can be a wholesale replacement for PLPA.

[ompiteam]

Imported from trac issue 4. Created by jsquyres on 2009-09-22T09:58:06, last modified: 2009-12-28T05:56:38

[ompiteam]

Trac comment by bgoglin on 2009-10-18 14:35:03:

Pavan Balaji works on the MPICH/Hydra port, he would like a way to know when we try to configure hwloc on a non-supported platform. Current configure just warns, we might want to error-out instead (maybe only if some "strictly-supported" flag is given) and/or add a #define HAVE_UNSUPPORTED_OS to config.h.

[ompiteam]

Trac comment by jsquyres on 2009-10-19 14:25:26:

Adding Pavan to the ticket...

Adding embedded capabilities is in the near future. I'm open to input here -- I was planning to do something like PLPA here, where you do something like this:

HWLOC_INIT(srcdir, action_on_success, action_on_fail)

This is the pattern we use throughout OMPI's configure m4 mojo; it's also what we did in PLPA. Pavan -- is that kosher for MPICH2 as well?

[ompiteam]

Trac comment by balaji on 2009-10-19 16:05:00:

This might or might not work for MPICH2 depending on how the m4 macro is setup. We currently stay away from libtool and just rely on automake/autoconf together with a bunch of our internal scripts. All third-party packages are configured directly and not added as AC_LOCAL_SUBDIRS in our configure.in/ac scripts. See http://trac.mcs.anl.gov/projects/mpich2/browser/mpich2/trunk/src/pm/hydra/configure.in?rev=5480#L346 for example.

Basically, if HWLOC_INIT() relies on any libtool macros, we cannot call it from MPICH2's configure scripts directly. If not, we should be fine.

[ompiteam]

Trac comment by jsquyres on 2009-10-19 16:34:34:

I was planning to pretty much carbon-copy PLPA's setup scheme. plpa.m4 doesn't use any Libtool macros (its top-level configure.ac does, but an embedded scenario wouldn't use that), but its Makefile.am's do assume the use of Libtool.

How do you handle that in MPICH2?

[ompiteam]

Trac comment by balaji on 2009-10-19 16:38:10:

We don't use PLPA's configure routines in MPICH2. We directly use the source files. So, we didn't run into this issue earlier.

[ompiteam]

Trac comment by jsquyres on 2009-10-19 16:42:45:

Ok. So you want to use hwloc's (upcoming) hwloc.m4, in which we'll likely have something like HWLOC_INIT(srcdir, action_on_success, action_on_failure). I'm guessing that that will be fine for you:

{{{

Make a hard-stop on failure

HWLOC_INIT([.], [], [AC_MSG_ERROR([hwloc configure failed!])])

Just set a shell variable indicating success/failure

HWLOC_INIT([.], [hwloc_success=1], [hwloc_success=0])
}}}

If you don't use our Makefile.am's, you should be fine -- you can use whatever your normal build system is. The question is then just to ensure that you can use our hwloc.m4 output (e.g., any AC_DEFINE's, AM_CONDITIONAL's, etc.). Do you use Automake, or is that also a no-no?
you can have an AC_MSG_ERROR if you want a hard-stop on failure, or something more benign (e.g., hwloc_success=0)

[ompiteam]

Trac comment by jsquyres on 2009-10-19 16:44:10:

Oops -- excuse the cut-n-paste error in the last comment (the last phrase was left over and should have been deleted: "you can have an AC_MSG_ERROR ...").

[ompiteam]

Trac comment by balaji on 2009-10-19 16:56:12:

Yes, I believe that'll be sufficient. The MPICH2/Hydra configure can do an HWLOC_INIT(), and if successful, it can call hwloc's actual configure. If you have a pre-release version of hwloc.m4, I'll be happy to test it out to make sure things work as expected.

[ompiteam]

Trac comment by jsquyres on 2009-10-19 17:50:29:

Ah -- miscommunication: I meant that HWLOC_INIT() ''is'' effectively hwloc's configure script. That is, hwloc's configure.ac will essentially be a little setup, calling HWLOC_INIT(), and then a little finalization. Hence, the intent is that you effectively embed our configure in your configure.

Are you looking to fork/exec hwloc's shell script configure executable directly, and then invoke "make [target]" in the hwloc subdirectory? That should work if you're not looking to embed our configure in yours. ...or is there something currently broken with that scheme?

(I have no pre-release hwloc.m4 yet -- I was out all week and this still remains on my to-do list)

[ompiteam]

Trac comment by balaji on 2009-10-19 18:02:16:

That'll work fine as well as long as HWLOC_INIT has none of the libtool macros that are present in hwloc/configure.ac currently. Yes, we are doing a fork/exec of hwloc's configure executable directly (for now).

[ompiteam]

Trac comment by jsquyres on 2009-10-19 20:45:40:

Ok -- but do you really want to (effectively) run hwloc's configure twice? Because if you call HWLOC_INIT() and then fork/exec hwloc's configure if HWLOC_INIT runs action_on_success, that's what you'll be doing.

Do you want just a sensible error abort from hwloc's configure if it fails? E.g., return non-zero status? That would give you a way to know if it succeeds or fails today, and as your text implies that you might want to embed someday, switching to HWLOC_INIT() in the future could also be possible.

[ompiteam]

Trac comment by balaji on 2009-10-19 21:23:55:

Yes, the configure error'ing out is the easiest as far as MPICH2/Hydra is concerned. However, even if I didn't fork/exec, but instead just called hwloc's configure as a sub-configure, how can I avoid configuring twice, assuming we want to find whether hwloc is supported on that platform at configure time?

An alternative to avoid doing the configure twice is for hwloc to never fail on configure, but to fail in the hwloc init call.

[ompiteam]

Trac comment by balaji on 2009-10-19 21:37:08:

Replying to [comment:12 balaji]:

An alternative to avoid doing the configure twice is for hwloc to never fail on configure, but to fail in the hwloc init call.

For clarity, by "hwloc init call" here I mean the library init call, not the HWLOC_INIT macro.