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