There was some confusion yesterday at the developer’s meeting over a topic regarding framework dependencies. I apologize - I should have looked over the agenda more closely in advance to ensure I recalled everything. Instead of the topic I had wanted to discuss, we wound up discussing embedding dependency arguments in component definitions.
What I really wanted to raise was the issue of statically including all base framework definitions in the core library. In other words, if you want to define a new framework for ORTE, you _must_ put the framework header and the base directory in libopen-rte. This makes it impossible for a 3rd party to add an ORTE framework - they have to get the OMPI community to add it upstream first. Note that you _can_ add components dynamically - you just can’t add a framework. The only solution a 3rd party has today is to create another project layer in the code, and put the framework there. However, this may be somewhat limiting due to circular build dependencies if, for example, an ORTE component needed to reference the new framework, and the new project/framework has an explicit link to libopen-rte. Resolving this would require that we dynamically load the frameworks themselves, and not just the components. This point is what led to Jeff’s proposal about dependencies - however, the dependency definitions are not _required_ in order to make this change. So the question to the community is: does anyone see an issue with making frameworks into dll’s? Obviously, this approach won’t work for static builds, but that is a separate issue. Thanks Ralph
