please consider prefixing under "martchus-" namespace

[sten0]

Hi @Martchus,

Thank you for syncthingtray, and its dependencies. I have been planning to package them for Debian for some time. All derivatives such as Ubuntu will also benefit. Would you please consider prefixing cpp-utilities under "martchus-" namespace? eg: marchus-c++utilities rather than c++utilities. Providing a mechanism to do this during built-time would also work. The issue is that Debian has many packages, and names like c++utilities will eventually cause conflicts between packages. No need to rename the project, of course!

Thank you for your consideration, Nicholas

[Martchus]

I've checked before on pages like https://repology.org and there were no other projects with that names.

Nevertheless the build system supports the feature you're looking for. This feature is actually intended to install multiple configurations within the same prefix (e.g. static vs. shared or Qt 5 vs. Qt 6 at some point). To use it one can set the CMake variable CONFIGURATION_NAME to something. This will not affect the library name because it might differ anyways (e.g. static vs. shared). In your case the library name must be changed as well so you also need to set CONFIGURATION_TARGET_SUFFIX in accordance. I haven't tested the CONFIGURATION_TARGET_SUFFIX variable much but if you run into issues they're likely easy to fix.

[Martchus]

Note that you need to pass CONFIGURATION_PACKAGE_SUFFIX in accordance when building qtutilities and syncthingtray so the build systems of these projects know under which name to look. You also need to use a consistent configuration name for all involved projects/libraries.

Examples can be found here (the scripts are targeting Windows but that shouldn't matter for this part):

• https://github.com/Martchus/PKGBUILDs/blob/master/c%2B%2Butilities/mingw-w64/PKGBUILD#L50
• https://github.com/Martchus/PKGBUILDs/blob/master/qtutilities/mingw-w64/PKGBUILD#L52

[Martchus]

By the way, if you manage to create Debian packages, feel free to mention them under https://github.com/Martchus/syncthingtray#packages-and-binaries.

[sten0]

Martchus notifications@github.com writes:

By the way, if you manage to create Debian packages, feel free to mention them under https://github.com/Martchus/syncthingtray#packages-and-binaries.

Thank you. It might take me a while, but yes, I will file a PR when the packages are in the archive.

[sten0]

Hi @Martchus

Thank you very much for the help! :-) Reply follows inline.

Martchus notifications@github.com writes:

I've checked before on pages like https://repology.org and there were no other projects with that names.

Thank you for checking. In the Debian there's been a shift to avoid packaging anything under top-level namespace. Eg: A Python application named 'foo' becomes 'python-foo'. Of course that's a fairly superficial thing ;-) In this case my concern is that "c++utilities" may someday end up as a reserved glibc or gcc soname, and I'd rather preempt the hypothetical issue. Other than that I'll concede it may be one of those pedantic "maximal correctness" technical values that are part of Debian culture...

Nevertheless the build system supports the feature you're looking for. This feature is actually intended to install multiple configurations within the same prefix (e.g. static vs. shared or Qt 5 vs. Qt 6 at some point). To use it one can set the CMake variable CONFIGURATION_NAME to something. This will not affect the library name because it might differ anyways (e.g. static vs. shared). In your case the library name must be changed as well so you also need to set CONFIGURATION_TARGET_SUFFIX in accordance. I haven't tested the CONFIGURATION_TARGET_SUFFIX variable much but if you run into issues they're likely easy to fix.

Thanks this helped a lot. In particular, I was stumped with getting to soname to match, because I didn't see CONFIGURATION_TARGET_SUFFIX in the docs and at present my knowledge of CMake is...inadequate...to put it lightly ;-)

Warm regards, Nicholas

[Martchus]

because I didn't see CONFIGURATION_TARGET_SUFFIX in the docs and at present my knowledge of CMake is...inadequate

I only added it to the docs quite recently and knowledge about CMake in general wouldn't have helped anyways because the "configuration name" feature is a personal hack which is within my build scripts.

I'm now using it myself for the GNU/Linux target (to be able to install regular releases and development builds within the same prefix). I've only noticed slight issues so far but nothing which would prevent you from using it when building Syncthing Tray. So I guess this issue can be closed unless there's something missing from your side.

[sten0]

Martchus notifications@github.com writes:

because I didn't see CONFIGURATION_TARGET_SUFFIX in the docs and at present my knowledge of CMake is...inadequate

I only added it to the docs quite recently and knowledge about CMake in general wouldn't have helped anyways because the "configuration name" feature is a personal hack which is within my build scripts.

Thank you for your kind words :-) BTW, from what I've learned about CMake, this flexibility is exactly the sort of thing it's designed for.

I'm now using it myself for the GNU/Linux target (to be able to install regular releases and development builds within the same prefix). I've only noticed slight issues so far but nothing which would prevent you from using it when building Syncthing Tray. So I guess this issue can be closed unless there's something missing from your side.

Ah, that's why you use a suffix and not a prefix! I feel like a prefix is more semantically correct for the system-wide default libdir, but I can't think of an argument that doesn't have an equally strong counter, so yes, feel free to close this issue. If prefix support is something you might add in the near future, please let me know.

Thanks again for the help! I ran into a busy spot in life so I'm not sure if I'll be able to finish the work on Syncthing Tray before the Ubuntu 20.04LTS's 27 Feb last-sync-from-debian deadline. Sorry about that... On the upside, I'm sure someone will create a PPA or backport :-)

Best, Nicholas

[Martchus]

If prefix support is something you might add in the near future, please let me know.

You can obviously install it right now into a separate prefix using the CMAKE_INSTALL_PREFIX variable. That is not different from any other CMake project. It has the disadvantage that binaries and libraries are not in standard search paths anymore so I would avoid it.

By the way, I would also avoid building Syncthing Tray itself with CONFIGURATION_TARGET_SUFFIX because otherwise the binaries will have non-standard names (which might not be expected by the users).

[sten0]

Martchus notifications@github.com writes:

If prefix support is something you might add in the near future, please let me know.

You can obviously install it right now into a separate prefix using the CMAKE_INSTALL_PREFIX variable. That is not different from any other CMake project. It has the disadvantage that binaries and libraries are not in standard search paths anymore so I would avoid it.

Oh, sorry, I mean soname prefix rather than CMAKE_INSTALL_PREFIX. With the suffix support you've provided we get:

libc++utilities-martchus.so.5.1.0

and symbols also have the "-martchus" postfix, which suggests that martchus is a subset of c++utilities rather than that c++utilities are under martchus namespace.

By the way, I would also avoid building Syncthing Tray itself with CONFIGURATION_TARGET_SUFFIX because otherwise the binaries will have non-standard names (which might not be expected by the users).

Thanks for the tip, I agree that could be confusing and have made a note to this effect.

Regards, Nicholas

[Martchus]

and symbols also have the "-martchus" postfix

Symbols are not affected by at all.

which suggests that martchus is a subset of c++utilities rather than that c++utilities are under martchus namespace.

Yes. Like I said, this feature is actually used for different configurations of the library and not for namespacing. Adding a suffix to the target/library would actually be easy. But it isn't possible for the configuration itself because I want to keep the code for finding CMake packages simple.

[sten0]

Resolved by #20 and #21. Closing.