search

conan-io / conan-center-index

Recipes for the ConanCenter repository
https://conan.io/center
MIT License
960 stars 1.77k forks source link

[question] cunit/2.1-3 incompatible with cunit/2.1-3 from Bincrafters #4789

Open k0ekk0ek opened 3 years ago

k0ekk0ek commented 3 years ago

Hi! I've recently switched from the Bincrafters recipe to the one in ConanCenter. It caused some issues for me, I'm not sure if the changes are intentional, but other user maybe impacted as well(?)

  1. The Bincrafters package provided in a shared library by default, the package in ConanCenter provides a static library by default. Was this switch intentional? The more complex tests we had suddenly failed after the switch and it took me some time to figure out what was going on.
  2. The package in ConanCenter exports cunit-1.dll instead of cunit.dll. Is there a reasoning behind the change?

Thanks.

k0ekk0ek commented 3 years ago

For some reason the .lib is also called cunit.dll.lib, which seems odd?

SpaceIm commented 3 years ago

I guess differences come from that bincrafters cunit recipe relied on a custom unofficial CMakeLists, while CCI cunit recipe relies on official upstream build files (autotools).

shared option default value of recipes in CCI is always False (there are just few exceptions).

The name of the import lib with Visual Studio comes from autotools, we may want to rename this file since several build system (qmake I guess) may not understand an import lib with .dll.lib extension for Visual Studio.

k0ekk0ek commented 3 years ago

If static is the default policy that's fine. I'd be in favor of renaming the files though. The static version does name the file cunit.lib and CMake Find modules are also having trouble finding the file. Usually CMake will look for <library prefix>library<library suffix>, where on Linux that becomes <lib>library<.so> and on Windows it becomes library<.dll>. Probably best to make the names cunit.dll and cunit.lib respectively.

SpaceIm commented 3 years ago

dll name doesn't matter for CMake, it's not used at link time (and renaming the dll after it was created might have side effects at runtime), but I agree that import lib should be renamed.

k0ekk0ek commented 3 years ago

The IMPORTED_LOCATION is normally the path of the .dll. Renaming the file makes it easier for find modules so they don't have to account for the -1. At least, that's what I just added :slightly_smiling_face: