CMake: enforcing a relationship between namespaces and library file names

Question

It seems that CMake does not support defining a relationship between the namespace of an exported or installed target and the name of the corresponding library file.

So, for example, CMake makes it easy to create packages that contain unambiguously named targets such as MyOrg::MyLibrary (using the NAMESPACE options of the export(EXPORT ...) and install(EXPORT ...) commands, but the actual .a, .lib, .so, or .dll files would still get globally-spaced names such as libMyLibrary.a: the namespace does not enter into the library filename.

It is of course possible to apply namespaces to your targets yourself; in the above example, you could name your target MyOrgMyLibrary, leading to a library filename such as "libMyOrgMyLibrary.a". Which is ok I guess, except that this makes the NAMESPACE option essentially useless (or you'd end up with targets named MyOrg::MyOrgMyLibrary), making me think that I'm missing something.

Is there a way to override the name of a generated library ? Or what would be the "right" way with CMake to ensure that library files get unambiguous names ?

Answer 1

The whole namespace thing is a lot less powerful than the name suggests. It's really not much more than a naming convention. I see the main advantage in huge frameworks that ship with lots of libraries (like Qt), but you are right, it is not too useful on its own.

Also note the mechanism is only concerned about avoiding name clashes in CMake scripts, not about name clashes on the filesystem. The latter need to be resolved on another level. The simplest way to avoid these is of course to have libraries install to a subdirectory. Then you pretty much only need to worry about nameclashes inside your own project. Unfortunately, this approach has its own drawbacks. On Unixes, users are discouraged from creating subdirectories to /usr/lib, except for storing application specific libraries (thanks to @JPNotADragon for pointing this out).

Otherwise, the usual techniques like prefixing apply, which you already mentioned.

I agree, this feature is not as powerful as one might wish. But then again, nameclashes are a non-trivial problem and in the end reasonable naming conventions are probably still the best solution.