It's instantiated in lib/MTT/Test.pm.
It's filled in by LoadBuilds in the same file (i.e., when the results of a
prior test build is loaded in from the dump file) and at the bottom of
lib/MTT/Test/Build.pm::_do_build(), when the build has completed and it saves
the results to the MTT:Test::builds hash.
On Nov 4, 2010, at 1:59 PM, DongInn Kim wrote:
> I am sorry that I was confused with the variable definition. My question
> should be how "$MP::Test::builds" is defined.
>
> Regards,
>
> On 11/4/10 1:42 PM, DongInn Kim wrote:
>> Thank you for all the detailed explanations, Jeff.
>>
>> Yes, if we can manage the MPI part with more generic term, that would be
>> really great so that we can use the same main framework without diverging to
>> another perl module to deal with FTT or something like this.
>>
>> Basically, how the "$MTT" is defined and setup in "$MTT::Test::builds"?
>>
>> It is used in MTT/Test/Run.pm and I could not find how it is defined. If I
>> find it, I think I can figure out what is going on here.
>>
>> Regards,
>>
>> On 11/4/10 11:54 AM, Jeff Squyres wrote:
>>> On Nov 4, 2010, at 8:46 AM, Joshua Hursey wrote:
>>>
>>>> Just for context. DongInn and Abhishek are working on support for testing
>>>> of the CIFTS FTB project with MTT. So this would be a non-MPI testing
>>>> target. They are currently working through some of the issues with
>>>> supporting an FTB target in the MTT client. I am working with them on
>>>> getting a new server setup (i.e., database, reporter) for that project.
>>>
>>> It might be worthwhile to s/MPI/Middleware/gi throughout the code, or, more
>>> specifically, support both "Middleware Install" and "MPI Install" tags in
>>> the ini file, etc.
>>>
>>> (i.e., we can't ditch "MPI Install" and friends because of the OMPI
>>> community using MTT, but if CIFTS and HDF are looking at using MTT, it
>>> might make sense to finally make the names a bit more generic)
>>>
>>>>> I found that the several keys of the hash($MTT::Test::builds) are empty
>>>>> in the middle of mtt/lib/MTT/Test/Run.pm:123
>>>>>
>>>>> DB<12> p Dumper(\%{$MTT::Test::builds})
>>>>> $VAR1 = {
>>>>> '' => {
>>>>> '' => {
>>>
>>> As you surmise below, you're correct: the above two empty fields should be
>>> the names from the MPI Get phase and the corresponding version.
>>>
>>>>> 'platform' => {
>>>
>>> You might want a bit more specific name than "platform" here. :-)
>>>
>>>>> 'ftb-examples' => {
>>>>> 'mpi_version'
>>>>> => undef,
>>>
>>> IIRC, the MPI::Get module is responsible for setting this value in the data
>>> structure that it returns, and it is propagated downward from there.
>>>
>>>>> 'mpi_name' =>
>>>>> undef,
>>>
>>> I'm pretty sure that this is the name from the MPI::Install phase.
>>>
>>>>> 'prepend_path'
>>>>> => undef,
>>>>> 'env_modules'
>>>>> => undef,
>>>>> 'setenv' =>
>>>>> undef,
>>>>> 'unsetenv' =>
>>>>> undef,
>>>>> 'append_path'
>>>>> => undef,
>>>
>>> These values all come directly from the INI file. If you didn't supply
>>> them, it's ok for them to be undef.
>>>
>>> prepend_path is stuff to be prepended to $path before running this section.
>>> append_path is the same, except to be appended to $path.
>>> setenv is stuff to be set in the environment before running this section.
>>> unsetenv is pretty much the same.
>>> env_modules are environment modules to be loaded before running this
>>> section.
>>>
>>> All of these cause changes to be effected before the section starts. The
>>> changes are effectively undone when the section ends (e.g., if an env
>>> module is loaded, it is unloaded when the section ends).
>>>
>>> These values also automatically propagate downwards -- any test runs that
>>> use this test build section will "inherit" all of these values before any
>>> tests are actually run, etc.
>>>
>>>>> 'description'
>>>>> => undef,
>>>
>>> This seems to come from the [MTT] section's "description" field. I forget
>>> offhand what it is for. I have "description = Cisco MPI development
>>> cluster" in my Cisco OMPI testing INI file.
>>>
>>>>>
>>>>> 'mpi_get_simple_section_name' => undef,
>>>
>>> This is also the name from the MPI::Get phase.
>>>
>>>>>
>>>>> 'mpi_install_id' => undef,
>>>
>>> The MPI::Install module is responsible for setting this... although I don't
>>> see where any current MPI::Install module fills in that value. It might be
>>> left over old kruft. :-\
>>>
>>
>
> --
> - DongInn
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
