Re: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol

2014-07-31 Thread Kenneth A. Lloyd 
Yeah, I forgot that pure ANSI C doesn't really have namespaces, other than
to fully qualify modules and variables. Bummer.

Makes writing large, maintainable middleware more difficult.

-Original Message-
From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Kenneth A.
Lloyd
Sent: 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.

-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 MPI Developers
Subject: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs.
mca_FRAMEWORK_COMPONENT_symbol

Jeff and I were talking about some namespacing issues that have come up in
the recent BTL move from OMPI to OPAL.  AFAIK, the current system for
namespacing external symbols is to name them
"mca_FRAMEWORK_COMPONENT_symbol" (e.g., "mca_btl_tcp_add_procs" in the tcp
BTL).  Similarly, the DSO for the component is named
"mca_FRAMEWORK_COMPONENT.so" (e.g., "mca_btl_tcp.so").

Jeff asserted that the eventual goal is to move to a system where all MCA
frameworks/components are also prefixed by the project name.  So the above
examples become "mca_ompi_btl_tcp_add_procs" and "mca_ompi_btl_tcp.so".
Does anyone actually care about pursuing this goal?

I ask because if nobody wants to pursue the goal of adding project names to
namespaces then I already have an easy solution to most of our namespacing
problems.  OTOH, if someone does wish to pursue that goal, then I have a
namespace-related RFC that I would like to propose (in a subsequent email).

-Dave

___
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/07/15371.php


-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4716 / Virus Database: 3986/7949 - Release Date: 07/30/14

___
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/07/15392.php


-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4716 / Virus Database: 3986/7951 - Release Date: 07/30/14

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 MPI Developers
Subject: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs.
mca_FRAMEWORK_COMPONENT_symbol

Jeff and I were talking about some namespacing issues that have come up in
the recent BTL move from OMPI to OPAL.  AFAIK, the current system for
namespacing external symbols is to name them
"mca_FRAMEWORK_COMPONENT_symbol" (e.g., "mca_btl_tcp_add_procs" in the tcp
BTL).  Similarly, the DSO for the component is named
"mca_FRAMEWORK_COMPONENT.so" (e.g., "mca_btl_tcp.so").

Jeff asserted that the eventual goal is to move to a system where all MCA
frameworks/components are also prefixed by the project name.  So the above
examples become "mca_ompi_btl_tcp_add_procs" and "mca_ompi_btl_tcp.so".
Does anyone actually care about pursuing this goal?

I ask because if nobody wants to pursue the goal of adding project names to
namespaces then I already have an easy solution to most of our namespacing
problems.  OTOH, if someone does wish to pursue that goal, then I have a
namespace-related RFC that I would like to propose (in a subsequent email).

-Dave

___
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/07/15371.php


-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4716 / Virus Database: 3986/7949 - Release Date: 07/30/14

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 this case the default OPAL build will only propose generic
connection capabilities, such as connection method using an atomic file
opening operation. However, the OMPI layer could provide a connector
components, that will expose the same interface as the OPAL connectors, but
will have access to the RML communications via the selected RTE. Today,
because the project name is not in the naming scheme such an approach is
possible...

  George.


  George.



On Wed, Jul 30, 2014 at 5:40 PM, Ralph Castain  wrote:

> 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 Jul 30, 2014, at 2:34 PM, Dave Goodell (dgoodell) 
> wrote:
>
> > Jeff and I were talking about some namespacing issues that have come up
> in the recent BTL move from OMPI to OPAL.  AFAIK, the current system for
> namespacing external symbols is to name them
> "mca_FRAMEWORK_COMPONENT_symbol" (e.g., "mca_btl_tcp_add_procs" in the tcp
> BTL).  Similarly, the DSO for the component is named
> "mca_FRAMEWORK_COMPONENT.so" (e.g., "mca_btl_tcp.so").
> >
> > Jeff asserted that the eventual goal is to move to a system where all
> MCA frameworks/components are also prefixed by the project name.  So the
> above examples become "mca_ompi_btl_tcp_add_procs" and
> "mca_ompi_btl_tcp.so".  Does anyone actually care about pursuing this goal?
> >
> > I ask because if nobody wants to pursue the goal of adding project names
> to namespaces then I already have an easy solution to most of our
> namespacing problems.  OTOH, if someone does wish to pursue that goal, then
> I have a namespace-related RFC that I would like to propose (in a
> subsequent email).
> >
> > -Dave
> >
> > ___
> > 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/07/15371.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/07/15372.php
>

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 Jul 30, 2014, at 2:34 PM, Dave Goodell (dgoodell)  wrote:

> Jeff and I were talking about some namespacing issues that have come up in 
> the recent BTL move from OMPI to OPAL.  AFAIK, the current system for 
> namespacing external symbols is to name them "mca_FRAMEWORK_COMPONENT_symbol" 
> (e.g., "mca_btl_tcp_add_procs" in the tcp BTL).  Similarly, the DSO for the 
> component is named "mca_FRAMEWORK_COMPONENT.so" (e.g., "mca_btl_tcp.so").
> 
> Jeff asserted that the eventual goal is to move to a system where all MCA 
> frameworks/components are also prefixed by the project name.  So the above 
> examples become "mca_ompi_btl_tcp_add_procs" and "mca_ompi_btl_tcp.so".  Does 
> anyone actually care about pursuing this goal?
> 
> I ask because if nobody wants to pursue the goal of adding project names to 
> namespaces then I already have an easy solution to most of our namespacing 
> problems.  OTOH, if someone does wish to pursue that goal, then I have a 
> namespace-related RFC that I would like to propose (in a subsequent email).
> 
> -Dave
> 
> ___
> 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/07/15371.php

[OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol

2014-07-30 Thread Dave Goodell (dgoodell) 
Jeff and I were talking about some namespacing issues that have come up in the 
recent BTL move from OMPI to OPAL.  AFAIK, the current system for namespacing 
external symbols is to name them "mca_FRAMEWORK_COMPONENT_symbol" (e.g., 
"mca_btl_tcp_add_procs" in the tcp BTL).  Similarly, the DSO for the component 
is named "mca_FRAMEWORK_COMPONENT.so" (e.g., "mca_btl_tcp.so").

Jeff asserted that the eventual goal is to move to a system where all MCA 
frameworks/components are also prefixed by the project name.  So the above 
examples become "mca_ompi_btl_tcp_add_procs" and "mca_ompi_btl_tcp.so".  Does 
anyone actually care about pursuing this goal?

I ask because if nobody wants to pursue the goal of adding project names to 
namespaces then I already have an easy solution to most of our namespacing 
problems.  OTOH, if someone does wish to pursue that goal, then I have a 
namespace-related RFC that I would like to propose (in a subsequent email).

-Dave