On May 7, 2013, at 11:34 AM, Thomas Naughton <naught...@ornl.gov> 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 naught...@ornl.gov
> 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 <r...@open-mpi.org> wrote:
>>
>>>
>>> On May 7, 2013, at 6:19 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com>
>>> wrote:
>>>
>>>> On May 6, 2013, at 10:39 PM, Ralph Castain <r...@open-mpi.org> 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
>>>> jsquy...@cisco.com
>>>> For corporate legal information go to:
>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> de...@open-mpi.org
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
