On Jul 9, 2009, at 2:17 PM, Eugene Loh wrote:
> The wiki said all public symbols and filenames. I assume filenames
> may
> leave off "<layer>_". That is, the file is properly named btl_sm.c
> rather than mca_btl_sm.c or ompi_btl_sm.c. Right?
>
Correct. The intent here (for filenames) is that if you --disable-
dlopen, then all the component .o files get slurped into
the .a / .so. And you can't have 2 of the same .o filename in a
single library. Hence, the prefix rule is needed to guarantee
uniqueness of filenames. But the layer name (or mca) is deemed
unnecessary -- we ruled that the <framework>_<component>_ prefix would
be unique enough.
Public symbols get a little more rigorious treatment (*must* have mca,
ompi, orte, or opal -- or MPI_ prefix) because we're a library. The
possibility that some user application has a variable named
"btl_sm_something" is quite possible -- "btl" and "sm" could have
entirely different meanings for them. Also, we can't control the user
app, so we wanted to be as conservative as possible.
That being said, we *can* control the filenames in our libraries. And
by definition, we'll never have a filename clash with a user
application. So we only need to prevent filename collisions within
our own code base. If a developer creates a file named ompi/runtime/
btl_sm_something.c, I think we'd prefer to simply shoot the developer
to solve the problem.
> As you have spoken, so has it been done. And, if someone would
> confirm
> the filename issue above, I'll update accordingly. Thanks for all the
> answers. Patch for 1962 on its way.
>
Many thanks Eugene!
--
Jeff Squyres
Cisco Systems
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}