Do not modify CMAKE_FIND_LIBRARY_PREFIXES and CMAKE_FIND_LIBRARY_SUFFIXES on Windows

[traversaro]

🦟 Bug fix

Summary

CMAKE_FIND_LIBRARY_PREFIXES and CMAKE_FIND_LIBRARY_SUFFIXES are variables that are used by
CMake to change the behaviour of the find_library calls. Changing CMAKE_FIND_LIBRARY_SUFFIXES to .lib;.dll in the CMake config file of every ignition project affect silently any downstream project that calls find_package(ignition-<pkg>), even if transitevely, leading to subtle bugs, such as the one investigate in conda-forge/libignition-gazebo-feedstock#30 (comment) .

I tried to investigate why that code was there in the first place, and I tracked it back to c9beb6b#diff-ca85e9f4b24c567606682737f2466b715279730d7960ab5a5dd2a140f6ba2907R39 on the ign-cmake side, and back to gazebosim/gz-common@a0d286d#diff-c4216ffdb6192d9b0e30753bc4b385b7a38716c1dd6d73439e9b4f3c9b51fdddR37 on the ign-common side from which the ign-cmake code was copied. It seems that this was more a leftover rather then something that was actually fixing something, but I may be missing something fyi @nkoenig @mxgrey .

If a change in CMAKE_FIND_LIBRARY_SUFFIXES is actually needed, it should be done close to the actual affected find_library call, and the previous value of CMAKE_FIND_LIBRARY_SUFFIXES should be restored as soon as possible.

Checklist

• Signed all commits for DCO
• Added tests
• Updated documentation (as needed)
• Updated migration guide (as needed)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge

[j-rivero]

If a change in CMAKE_FIND_LIBRARY_SUFFIXES is actually needed, it should be done close to the actual affected find_library call, and the previous value of CMAKE_FIND_LIBRARY_SUFFIXES should be restored as soon as possible.

Agree. We need to evaluate what changes this PR will bring and the impact of them in the current use cases or distributions of the libraries. Does these changes modify the filenames of the produced libraries?

Let's start by running a testing build of ign-gazebo6 (Fortress) with custom gazebodistro with this PR in cmake2 .

[traversaro]

Does these changes modify the filenames of the produced libraries?

As long as I am aware of, no. I checked directly on CMake source code to be sure, and the only use (excluding Find<>.cmake scripts, tests and Platform files) of that variables is indeed in the find_library implementation:

• https://github.com/Kitware/CMake/blob/5bd94332c760a6f861b411273921b204076ab9a6/Source/cmFindLibraryCommand.cxx#L271
• https://github.com/Kitware/CMake/blob/5bd94332c760a6f861b411273921b204076ab9a6/Source/cmFindLibraryCommand.cxx#L286

So I think we can safely exclude that in some way this change should affect the file name of the libraries.

Let's start by running a testing build of ign-gazebo6 (Fortress) with custom gazebodistro with this PR in cmake2 .

Cool, that's a great way to test this.

[traversaro]

Let's start by running a testing build of ign-gazebo6 (Fortress) with custom gazebodistro with this PR in cmake2 .

Cool, that's a great way to test this.

The test is failing but I guess it is related to gazebosim/gz-sim#990 ? As an alternative test, I also backported this change in conda-forge (conda-forge/libignition-cmake0-feedstock#20) to fix conda-forge/libignition-gazebo-feedstock#30, I can re-build a few ignition libraries and see if there are problems.

[j-rivero]

Another try

[j-rivero]

Another try

The build failed due to a bug in cmake for an old vcpkg snapshot. Seems like the change is not afffecting in anyway the procedure to find dependencies. Sounds good enough to me to go.

[osrf-triage]

This pull request has been mentioned on Gazebo Community. There might be relevant details there:

https://community.gazebosim.org/t/new-ignition-releases-2022-01-10/1228/1