search

snitch-org / snitch

Lightweight C++20 testing framework.
Boost Software License 1.0
259 stars 7 forks source link

Please consider making all files installed by the header-only version different from files installed by the library version #125

Closed yurivict closed 1 year ago

yurivict commented 1 year ago

Currently the file lib/cmake/snitch/snitch-config.cmake is installed by both.

In FreeBSD we would like to be able to install both flavors simultaneously, but these flavors conflict on this file.

Maybe it can be removed into lib/cmake/snitch/snitch-header-only-config.cmake ?

tocic commented 1 year ago

There are identical. You can check that by running diff on them.

yurivict commented 1 year ago

But they still conflict because two different packages install the same file.

tocic commented 1 year ago

Which tool says that there are in conflict? I mean cmake --install just overwrites the file and since there are identical there's no problem in that.

yurivict commented 1 year ago

FreeBSD's pkg install snitch-testing-headers-only complains that it conflicts with snitch-testing and can't be installed.

In general packages can't overwrite each other's files.

cmake of course overwrites files because it is a build tool, not a packaging tool.

tocic commented 1 year ago

If there are 2 packages then I agree. I've just packaged them in one.

yurivict commented 1 year ago

But then both flavors would be installed all the time.

cschreib commented 1 year ago

Hi both, and thanks for reporting this. @tocic is correct, the file is the same in both cases, and that is on purpose, so one can install multiple builds of snitch together and be found as snitch.

If I make the file name different in both builds, then one cannot do 

find_package(snitch CONFIG)

... and get both the snitch::snitch and snitch::header-only targets at once. That is because CMake find_package(X) looks for X-config.cmake; if the file name is different, then the find_package call will be different, e.g. find_package(snitch-header-only).

That's possible, but not really how things are normally done in CMake, so I expect people would find it surprising. I don't know how other packages handle this, but see e.g. Boost and SFML; they both are a single "library" with multiple "components" that can be installed separately. Perhaps the same packaging solution can be reused here?

Please let me know if this requires support on our end.

cschreib commented 1 year ago

FYI I'm having to issue another bug-fix release (1.2.2) because the CMake scripts don't actually work with CMake 3.14; I was still unknowingly using 3.19 features. I'll hold off for a day or so in case another change needs to be done to close this issue.

cschreib commented 1 year ago

I don't use FreeBSD so please bear with me, but from what I can tell from the FreeBSD ports, the two examples I gave above (SFML and Boost) are each packaged as a single master package (sfml and boost-libs) rather than multiple packages where each sub-library can be installed separately.

Based on this, my suggestion would be indeed to always package the compiled and header-only versions together. You could also make one dependent on the other, so the dependent package would not install the root config file, but that seems a bit arbitrary to me.

yurivict commented 1 year ago

I've made them into flavors for now on FreeBSD. Maybe will merge them later, but that would be more work.

cschreib commented 1 year ago

I will close this issue if this resolved, but feel free to re-open if you want to discuss this further. Thank you for the feedback!