not a requirement of course, but warm recommendation. Like you mentioned: "component developers who choose to expose such information do so using the suggested syntax, then that is a different proposal."
>>>FWIW: we do not (and cannot, for licensing reasons) link against Slurm, so please don't include it in such lists to avoid giving anyone even a passing thought that we do so. I don`t understand, today we have "--with-slurm --with-pmi" for dynamic link with slurm and others where we call slurm functions from OMPI code. how calling slurm.getVersion() is different? afaik, dynamic linking (as we do it today) does not violate current licensing model. On Fri, Apr 25, 2014 at 5:39 AM, Ralph Castain <r...@open-mpi.org> wrote: > Just for clarification: are you proposing that we *require* every > component that links against an external library to include these > parameters? If so, that seems a significant requirement as quite a few of > our components do so. > > On the other hand, if you are proposing that those component developers > who choose to expose such information do so using the suggested syntax, > then that is a different proposal. > > Just want to understand what you are proposing - a requirement on > components, or a syntax for those who choose to support this capability? > > FWIW: we do not (and cannot, for licensing reasons) link against Slurm, so > please don't include it in such lists to avoid giving anyone even a passing > thought that we do so. > > > > On Apr 23, 2014, at 10:38 PM, Mike Dubman <mi...@dev.mellanox.co.il> > wrote: > > > WHAT: > * Formalize well-known MCA parameters that can be used by any component to > represent external dependencies for this component. > > * Component can set that well-known MCA r/o parameters to expose to the > end-users different setup related traits of the OMPI installation. > > Example: > > ompi_info can print for every component which depends on external library: > - ext lib runtime version used by component > - ext lib compiletime version used by component > > slurm: v2.6.6 > mtl/mxm: v2.5 > btl/verbs: v3.2 > btl/usnic: v1.1 > coll/fca: v2.5 > ... > > End-user or site admin or OMPI vendor can aggregate this information by > some script and generate report if given installation compiles with > site/vendor rules. > > * The "well-known" mca parameters can be easily extracted from ALL > components by grep-like utilities. > > * Current proposal: > > ** prefix each well-known MCA param with "print_": > ** Define two well-known mca parameters indicating external library > runtime and compiletime versions, i.e.: > > print_compiletime_version > print_runtime_version > > The following command will show all exposed well-known mca params from all > components: > ompi_info --parsable -l 9 |grep ":print_" > > > WHY: > > * Better support-ability: site/vendor can provide script which will check > if OMPI installation complies to release notes or support matrix. > > > WHEN: > > - Next teleconf > - code can be observed here: > https://svn.open-mpi.org/trac/ompi/ticket/4556 > > > Comments? > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/04/14590.php > > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/04/14601.php >
