Hi all -
It's been a week or so since I horribly broke configure, so I thought
it was time for another stab at it. This time, the motivation was
the high resolution timers. The timers are different on pretty much
every platform, and have some weird intersections (for example, on
all IA64 Linux machines except the Altix, you have to use assembly to
get the counters. On the Altix, you use SGI's interface so you don't
have quite as much per-cpu jitter. This seems to scream for two
different components). We want at most one component to ever be
built - anything more and any rational scheme for doing inline
functions into the components will fail.
A framework can now (via a file configure.options in the mca/
[framework]/ directory) set options about how the framework should be
configured. Currently, the only option is STOP_AT_FIRST, which will
cause configure to only successfully configure at most one component
for the framework type. Any other option is taken to mean the
default "try to configure all components" system that has always been
in place. The way this works is that all the no configure components
are configured in the order specified by autogen.sh, then all the m4
configure components are configured in the order specified by
autogen.sh. As soon as one of them succeeds, no more components are
configured. For now, configure.stub components can not be used with
STOP_AT_FIRST (but can be with the default, usual system, yadda, yadda).
Now, you're probably asking yourself "what order does autogen.sh
specify?", and the answer would be "alphabetical". That not
necessarily being useful for stopping at the first useable component,
you can now specify a "listing priority" in configure.params for a
component which is, you guessed it, an integer that gives a sorting
ranking for the given components, higher numbers are earlier in the
list. Components default to a priority of 0, and the sort is stable
(so components with the same priority stay in alphabetical order).
This is probably not useful for anything outside of OPAL, but seems
to be fairly useful for all three OPAL frameworks. I haven't had a
chance to write up the documentation in the design doc just yet
(coming soon, I promise!) and the timer framework isn't quite ready
to commit yet, so there isn't a good example. I should have at least
the base of the timer framework and the x86 linux component committed
tomorrow evening, so there will be an example then of what I'm
talking about.
Anyway, I'm 99.99% sure that I didn't break anything. Let me know
what I missed...
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
