WHAT: Split configury across the opal, orte, and ompi trees as relevant.
WHERE: mostly configure.ac, 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)
Details:
Cisco recently had a desire to fix the long-broken -no-ompi option to
autogen.sh. 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 (https://svn.open-mpi.org/trac/ompi/ticket/2062
).
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 autogen.sh 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)?
Thanks!
--
Jeff Squyres
jsquy...@cisco.com
