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 >
