Namespace name?
SimonHeybrock opened this issue · 4 comments
We are trying to use LLNL/units in another project which also defines a (nested) namespace units. This clashes with namespace units from this. Ideally having units nested in another namespace would solve this issue, e.g., namespace llnl::units.
I assume changing this would break other libraries using units, so probably another option is required:
I have two solutions for this:
- We are using
LLNL/unitsas acmakeexternal project. We apply a patch to add a top levelnamespace llnl. Works, but requires maintainance whenunitsupdates and patching fails. - Add a
cmakeoption to define the top level namespace. I did this on https://github.com/SimonHeybrock/units/tree/cmake-define-namespace. If you think you would be willing to accept such a change, I would be happy to open a pull request from this.
A different but related question is related to the include path: Currently units is the top-level directory, so users of the library include, e.g., <units/units.hpp>. Since "units" is quite generic, having another prefix would be useful, for example as done by boost: <boost/units/units.hpp>.
I had toyed with the idea of changing the namespace to rtunits because as you said units is fairly generic and common. Haven't run into any conflict myself. Probably in a 1.0 release. That would probably involve changing the file names as well.
with the cmake option, that is interesting. I would want to make sure it works as a header only library, so just copying the files works fine and generates a default namespace that makes sense. I will explore that a bit further and get back to you.
I added some code for a cmake specified namespace in the cmake_namespace branch. Need to add some test code and documentation before merging but you can take a look if you like.
See also my branch https://github.com/SimonHeybrock/units/tree/cmake-define-namespace which has the relevant changes to allow building of the units tests.
Fixed by #136.