Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: [OMPI devel] RFC: configure / m4 reorganization
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-10-26 09:48:21

WHAT: Split configury across the opal, orte, and ompi trees as relevant.

WHERE: mostly, config/, opal/config/, orte/config/, and
ompi/config/, and various component configure.m4 scripts

WHY: To fix autogen's -no-ompi feature, fix the opalc++ and ortec++
wrapper compilers, and improve the layering in the OMPI build system

WHEN: Retroactive (see below)


Cisco recently had a desire to fix the long-broken -no-ompi option to So we did it, and along the way, it seemed useful to take
a first swipe at splitting up OMPI's m4 scriptery to be in each of the
projects where they are needed. Specifically:

- move OPAL-specific m4 to opal/config/
- move ORTE-specific m4 to orte/config/
- move OMPI-specific m4 to ompi/config/

We got it *mostly* right before committing to the trunk, but there
were a few lingering issues that took a few more commits over the next
day or three to get right (sorry!).

While waiting for some long compiles late last week, I took a second
swipe at further separating obvious project-specific configury. In
particular, I moved and renamed resource manager checks to orte/
config, and moved and renamed network checks to ompi/config.

Finally, we also fixed the opalc++ and ortec++ wrappers compilers --
there were a few long-standing problems with them that probably no one
had noticed/cared about.

We did not send out an RFC before doing any of this work because we
viewed the -no-ompi stuff as fixing a long-standing issue. We viewed
the m4 separation as a long-standing goal to help projects like STCI
and others (i.e., improve the distinct layering in the build system).
We didn't think that reorganizing the m4 stuff was a big deal, but in
hindsight, it did touch a lot of files and we probably should have
said something first. I found out after the fact that in doing this
work, we did expose at least one problem for another developer. :-
( Our apologies.

FWIW: it is unlikely that we'll be doing much (any?) further work on
separating the configury in the near future. Ralph filed a future-
looking ticket about what *could* be done, if someone gets ambitious (

All this being said, we're open to discussion about all the work that
was done. If someone objects to it, please let us know -- if
necessary, it may be possible to back out the project-specific m4
trees from the -no-ompi and wrapper compiler fixes.

Len -- can we add this to the agenda for tomorrow's teleconference,
and perhaps also next week (if people don't have time to think about
this in depth before tomorrow's teleconference)?


Jeff Squyres