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
