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