Re: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol

2014-07-31 Thread Kenneth A. Lloyd
: Thursday, July 31, 2014 6:04 AM To: 'Open MPI Developers' Subject: Re: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol Doesn't namespacing obviate the need for this convoluted identifier scheme? See, for example, UML package import and include behaviors

Re: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol

2014-07-31 Thread Kenneth A. Lloyd
Doesn't namespacing obviate the need for this convoluted identifier scheme? See, for example, UML package import and include behaviors. -Original Message- From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Dave Goodell (dgoodell) Sent: Wednesday, July 30, 2014 3:35 PM To: Open

Re: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol

2014-07-30 Thread George Bosilca
I can also picture an environment where different projects can supply component that would technically belong to a framework from another project. Let me take an example. Imagine we decide to keep the RML-based connection setup for SM, thing that is not currently possible in the OPAL layer. In

Re: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol

2014-07-30 Thread Ralph Castain
We've run into the same problem with frameworks in different projects having overlapping names, let alone symbols. So if you have an easy solution, please go for it. What we need is for not only the symbols, but the mca libs to contain the project names so they don't overlap each other. On