Arf; I just realized this is all moot -- ompi_info doesn't have the
argv given to OMPI's configure because we never figured out a way to
do that cleanly. :-\
On Feb 6, 2008, at 4:11 PM, Ethan Mallove wrote:
On Wed, Feb/06/2008 01:47:16PM, Jeff Squyres wrote:
If this is going to be an OMPI-module-specific field, then
running ompi_info is fine. But doesn't the GNU configure
MTT module already have the configure command line?
The scenario is that I'm using one plug-in to create Solaris
packages, but then I run tests against those packages using
an AlreadyInstalled MPI install. In other words, there is a
bit of a disconnect between the plug-in that accesses the
config.log and the plug-in that is actually used when
running the tests. It would be preferable to get the
configure options via ompi_info, if possible.
-Ethan
On Feb 6, 2008, at 1:44 PM, Josh Hursey wrote:
On Feb 6, 2008, at 11:32 AM, Ethan Mallove wrote:
For the configure options we *could* parse the config.log to
extract
this data. The question is, if we did this, what do we want to
look?
And is this something we want to do? Is there another way?
I think having a network-like field for the MPI install section
might
be good, and possibly have an OMPI:: funclet to automatically do
the
parsing. But we need to be mindful of MPIs that won't have a
configure script, so what information goes there might be dubious
(or
just empty?).
Yeah I think an Open MPI specific function should do the parsing
since
the configure options we want to grab will be specific to Open
MPI. I
think in the case of no configure script it would just be empty.
The info we are looking for in config.log is not available
in ompi_info? Parsing config.log throws a monkey wrench into
an AlreadyInstalled testing scenario.
I haven't looked to see for sure what the difference between the two
would be. But if ompi_info provides the information that we need,
then
we can use it. Otherwise then we should try to parse config.log if
it
is available.
If we are doing an MPI Install and the build fails (due to maybe an
enabled feature) then we will have to depend upon parsing config.log
to see exactly which fields are available since ompi_info will not
be
available to us at this point.
-- Josh
_______________________________________________
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
--
Jeff Squyres
Cisco Systems
_______________________________________________
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
_______________________________________________
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
--
Jeff Squyres
Cisco Systems
