OK, thanks. Jeff.
I am not sure that this is related to my original question but I was actually
looking for a way to have ftt find my test examples with the following.
#======================================================================
# Test Run phase
#======================================================================
# Some default Test run parameters to include in (most) Test run sections
[Test run]
pass = &and(&cmd_wifexited(), &eq(&cmd_wexitstatus(), 0))
timeout = &max(30, &multiply(10, &test_np()))
save_stdout_on_pass = 1
merge_stdout_stderr = 1
stdout_save_lines = 100
np = &env_max_procs()
specify_module = Simple
[Test run: ftb-examples]
include_section = Test run
test_build = ftb-examples
skipped = &and(&cmd_wifexited(), &eq(&cmd_wexitstatus(), 77))
# Similar rationale to the intel test run section
simple_first:tests = &find_executables( \
"ftb_eventhandle_example", \
"ftb_example_callback_unsubscribe", \
"ftb_multiplecomp", \
"ftb_notify_logger", \
"ftb_pingpong", \
"ftb_polling_logger", \
"ftb_simple_publisher", \
"ftb_simple_subscriber", \
"ftb_watchdog")
# Similar rationale to the intel test run section
simple_fail:tests = environment/abort environment/final
simple_fail:pass = &and(&cmd_wifexited(), &ne(&cmd_wexitstatus(), 0))
simple_fail:exclusive = 1
simple_fail:np = &env_max_procs()
The test example codes are listed in simple_first:tests.
But I don't think that those example codes are called to run at the "Test Run"
phase.
Regards,
On 11/4/10 2:35 PM, Jeff Squyres wrote:
> 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
>
>
--
- DongInn
