Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] [OMPI svn] svn:open-mpi r28456 - trunk
From: Thomas Naughton (naughtont_at_[hidden])
Date: 2013-05-07 14:34:12


Hi,

Briefly, I'm Thomas. I work at ORNL. I changed autogen.pl on my
first commit to OMPI trunk. (Insert rookie joke here. :-D)

The changes in r28456 for autogen.pl were pretty basic/minor. I
apologize for not sending a follow-up email to devel mailing list
outlining the changes -- poor netiquette on my part. :-/

There were four changes included in the patch. They related
mainly to the recent changes for MCA frameworks. I'll give a little
more description below.

Ralph, I also included your feedback and a response for #2. Let me
know if this makes sense as I think it provides the "right" behavior
but want to double check. Thanks.

> 1) Add ifdef guard to project's autogenerated "frameworks.h" header
> file, e.g., "opal/inlude/opal/frameworks.h" would have
> "OPAL_FRAMEWORKS_H".

This one simply adds and ifdef to top of auto-generated file, so if code
includes the "framework.h" file you avoid multiple includes of same file.
This is generic to the given project so the "opal/" project would generate
something like:

   $ cat opal/include/opal/frameworks.h
   /*
    * This file is autogenerated by autogen.pl. Do not edit this file by hand.
    */
   #ifndef OPAL_FRAMEWORKS_H
   #define OPAL_FRAMEWORKS_H

   #include <opal/mca/base/mca_base_framework.h>

   extern mca_base_framework_t opal_backtrace_base_framework;

      ...<snip>...

   #endif /* OPAL_FRAMEWORKS_H */

This would also be done for "ompi/" and "orte/" project directories.

> 2) Avoid adding "ignored" frameworks to the autogenerated "frameworks.h"
> header file.

This simply applies the same ignored() function that is used elsewhere in
the autogen.pl script for omitting "ignored" MCA directories from the
processing. This just picks up the ".ompi_ignore" (and/or ".ompi_unignore)
files. The intent being that if you ignore a component (subdir) that will
be removed from the list, but you could also remove an entire framework if
you put the ignore file in the top-level of the framework.

The intent being that if for whatever reason you ignore a framework in the
"${project}/mca/" space, you will not have it automatically show up in the
project's "frameworks.h" file.

On Tue, 7 May 2013, Ralph Castain wrote:

>> We use the frameworks.h file to "discover" the frameworks in
>> ompi_info. Even if no components are built for that framework,
>> there still are MCA params relating to the base of that framework.
>> Sounds silly, I know - but there may be reasons to access those
>> params - e.g., to set verbosity to verify that no components are
>> being selected.
>>
>> I think we need those frameworks to be listed...

Ok, I didn't realize the 'ompi_info' aspect. Good to know.
However, I think honouring the ignore behavior is good in this case
b/c if you drop an ignore file in a framework, you won't get any
other autogen touches (i.e., no Makefile's are autogenerated). So
it seems that having no Makefiles but including the framework in the
"framework.h" would break regardless. Again, this is more of a
safety guard.

> 3) Avoid adding non-MCA projects to the autogenerated
> 'mca_project_list', which maintains existing support for "projects"
> with new MCA framework enhancements. Moves this down to mca_run_global().

This was just a bit of shifting code and didn't sound like there was
any discussion on this point. This is a "do no harm" factor to
support pre-existing functionality. The gist is that if you have a
"project" in the build directory that doesn't have an MCA directory
structure, just avoid adding it to the list of MCA projects.

> 4) Add small loop at end to add projects with a "config/" subdir
> to the list of includes for 'autoreconf'.

This again is a "do no harm" factor to support pre-exising
functionality. If you have a "${project}/config/" directory. This
appends the "-I ${project}/config/" to the autoreconf list.
If you do not have a "${project}/config/" dir, there is no change.

Again, I hope that gives more context/description to the changes
included in the autogen.pl patch. In the future, I'll try to do
a better job of sending a heads up to the devel list.

Thanks,
--tjn

  _________________________________________________________________________
   Thomas Naughton naughtont_at_[hidden]
   Research Associate (865) 576-4184

On Tue, 7 May 2013, Ralph Castain wrote:

> Crud - it just struck me that you don't want to do one thing in that patch.
>
>> + Avoid adding "ignored" frameworks to the autogenerated "frameworks.h"
>> header file.
>
>
> We use the frameworks.h file to "discover" the frameworks in ompi_info. Even if no components are built for that framework, there still are MCA params relating to the base of that framework. Sounds silly, I know - but there may be reasons to access those params - e.g., to set verbosity to verify that no components are being selected.
>
> I think we need those frameworks to be listed...
>
>
> On May 7, 2013, at 6:49 AM, Ralph Castain <rhc_at_[hidden]> wrote:
>
>>
>> On May 7, 2013, at 6:19 AM, Jeff Squyres (jsquyres) <jsquyres_at_[hidden]> wrote:
>>
>>> On May 6, 2013, at 10:39 PM, Ralph Castain <rhc_at_[hidden]> wrote:
>>>
>>>> Could someone help me out a bit here:
>>>>
>>>> * I'm unaware of any mechanism for "ignoring" an entire framework. Was something added for that purpose?
>>>
>>> It's been in autogen.pl for a while -- check out the end of mca_process_framework() in autogen.pl.
>>
>> I see - you didn't mean "ignore the framework", you meant "ignore all components in this framework". The two are not the same thing. Ignoring the framework would mean that we were somehow going to skip the base as well, which couldn't possibly work. We've talked about that before and never could figure out how to null-out all the framework level functions.
>>
>>>
>>>> * What "non-MCA" projects are in our repository? Everything appears to be based on MCA plugins.
>>>>
>>>> * Looking at Trac, we eliminated all project/config directories when we did the OMPI-RTE abstraction. So what are we looping across at the end of autogen?
>>>
>>> Yes, we did. ORNL specifically asked me/Nathan off-list if they could add this loop in, because they have some off-trunk repos (e.g., STCI) that both still use the config/ directory stuff and have non-MCA projects. I didn't see any harm in these things; e.g., the loop only adds -I if the directory exists. I.e., I saw it as being an attempt to be friendly to those who are trying to use our lower laters (ORTE and/or OPAL) with non-OMPI projects. I thought this fit in well with the move-the-BTLs-down-to-OPAL philosophy.
>>>
>>> That being said, if others disagree -- e.g., Ralph has a valid point: this is to help projects that are outside of our trunk -- let's discuss. This will probably be a useful topic to discuss today on the teleconf.
>>
>> I don't object to it being there as it is a "no-op" for us - there was just no explanation given as to why this was being done. So it looked like a patch based on an old version of the trunk.
>>
>>
>>>
>>> --
>>> Jeff Squyres
>>> jsquyres_at_[hidden]
>>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>