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
