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
