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: Ralph Castain (rhc_at_[hidden])
Date: 2013-05-07 15:33:07


On May 7, 2013, at 11:34 AM, Thomas Naughton <naughtont_at_[hidden]> wrote:

> 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)

Welcome!

>
> 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.
>

No issues from anyone that I heard.

>
>
>
>> 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.

That is new - I would suggest not doing that as it behaves differently than you might expect. The .ompi_ignore in a component prevents that component from building at all, so it won't ever be opened etc. However, the framework *must* build the base code no matter what - and that means the framework will be opened, selected, and closed at the minimum.

I would prefer we keep ompi_ignore cleanly defined. You can ignore all components by simply putting --enable-mca-no-build=<framework> on your configure line.

>
> 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.
>
>

Actually, I disagree. As stated above, the framework will *always* build the base code and be opened, selected, and closed - so you at least need access to the verbosity parameter so you can verify those operations. Keeping it in ompi_info is of value.

>
>
>> 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.

No objections

>
>
>
>> 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.
>

No objections - I only flagged it because it made the patch appear to be derived from an old version of the trunk.

>
> 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.
>

Appreciated the details!
Ralph

> 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
>>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel