Ralph, The goal here is to allow vendor to distribute binary orte frameworks (on top of binary components they can already distribute) that can be used by a user compiled "stock" openmpi library).
Did I get it right so far ? I gave it some thoughts and found that could be simplified. My understanding is that such frameworks can only be used by 3rd party component(s) from an existing framework, am I right ? In this case, what about creating libopen-rte-ext.so with all the 3rd party frameworks (one library in case two frameworks need each other, and avoid circular dependencies). libopen-rte-ext.so does depend on libopen-rte.so, and 3rd party components depend on both rte libs. Build order is important : - libopen-rte.so - libopen-rte-ext.so - components But there is no circular build dependencies (e.g. libopen-rte.so does not depend on libopen-rte-ext.so), and there is no need to create an other project. The only restriction I can think of is it is impossible that 3rd party frameworks from vendor A and vendor B depend on each other. There could be frameworks from different vendors as long as they use distinct lib names for their extended orte lib. Any thoughts ? Gilles On Saturday, February 27, 2016, Ralph Castain <r...@open-mpi.org> wrote: > 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 > > _______________________________________________ > devel mailing list > de...@open-mpi.org <javascript:;> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2016/02/18634.php
