Backport PR #3030 to Gazebo9 for CURL fixes

[j-rivero]

Gazebo9 on Windows is currently failing with problems related to linking of CURL
against .dll instead of using .lib. Seems to me the name problem described and
solved by #3030.

This PR backports the code to gazebo9 branch.

[j-rivero]

Umm this same PR seems to be built just fine in a new job (clone of gazebo-ci-pr_any) on windows_mad

[scpeters]

Umm this same PR seems to be built just fine in a new job (clone of gazebo-ci-pr_any) on windows_mad

is something wrong with the workspace of the current CI job?

[j-rivero]

is something wrong with the workspace of the current CI job?

that or we have a problem somehow with vcpkg interacting into the tarball environment. Triggering a build in beefy to check how things are there:

[j-rivero]

that or we have a problem somehow with vcpkg interacting into the tarball environment. Triggering a build in beefy to check how things are there:

Failed on beefy. Somehow the problem might be related to the local context on it.

The fact of having the libcurl_imp.lib instead of libcurl_imp.dll in the compilation line is what is making the difference.

I've forced a curl removal from vcpkg on windows_mad using custom release-tools branch. Build is good (I cancelled it): https://build.osrfoundation.org/job/_test_gazebo-ci-pr_any-windows7-amd64/5 .

🟢 From success build:

cmake 3.15.5 run:

-- Could NOT find HDF5 (missing: HDF5_LIBRARIES HDF5_INCLUDE_DIRS C CXX) (found version "")
-- 	HDF5 not found
-- Found CURL: C:/Jenkins/workspace/_test_gazebo-ci-pr_any-windows7-amd64/ws/install/lib/libcurl_imp.lib (found version "7.57.0-DEV")  
-- Looking for libprofiler - not found
-- Looking for libtcmalloc - not found

From CMakeCache.txt:

//No help, variable specified on the command line.
CURL_FOUND:UNINITIALIZED=1

//Path to a file.
CURL_INCLUDE_DIR:PATH=C:/Jenkins/workspace/_test_gazebo-ci-pr_any-windows7-amd64/ws/install/include

//No help, variable specified on the command line.
CURL_LIBRARIES:UNINITIALIZED=libcurl_a

//Path to a library.
CURL_LIBRARY_DEBUG:FILEPATH=CURL_LIBRARY_DEBUG-NOTFOUND

//Path to a library.
CURL_LIBRARY_RELEASE:FILEPATH=C:/Jenkins/workspace/_test_gazebo-ci-pr_any-windows7-amd64/ws/install/lib/libcurl_imp.lib

Files in workspace:

jrivero@winMAD MINGW64 /C/Jenkins/workspace/_test_gazebo-ci-pr_any-windows7-amd64/ws
$ find . -name '*curl*'
./curl-7.57.0-vc15-x64-dll-MD.zip
./install/bin/curl-config
./install/bin/curl.exe
./install/bin/libcurl.dll
./install/CMake/curl-config-version.cmake
./install/CMake/curl-config.cmake
./install/CMake/curl-target-relwithdebinfo.cmake
./install/CMake/curl-target.cmake
./install/CMake/libcurl-target-relwithdebinfo.cmake
./install/CMake/libcurl-target.cmake
./install/include/curl
./install/include/curl/curl.h
./install/include/curl/curlver.h
./install/lib/libcurl_imp.lib
./install/lib/pkgconfig/libcurl.pc

🔴 For the bad build on beefy:

-- 	HDF5 not found
-- Found CURL: C:/Jenkins/workspace/_test_gazebo-ci-pr_any-windows7-amd64/ws/install/CMake/curl-config.cmake (found version "7.57.0-DEV")  
-- Looking for libprofiler - not found
-- Looking for libtcmalloc - not found

CMakeCache.txt

//The directory containing a CMake configuration file for CURL.
CURL_DIR:PATH=C:/Jenkins/workspace/_test_gazebo-ci-pr_any-windows7-amd64/ws/install/CMake

//No help, variable specified on the command line.
CURL_FOUND:UNINITIALIZED=1

//No help, variable specified on the command line.
CURL_LIBRARIES:UNINITIALIZED=libcurl_a
``  

[j-rivero]

I have an hypothesis: different versions of cmake are behaving differently in both machines. cmake 3.15.5 is in windows_mad while cmake 3.20.0 is in beefy. Checking the different release notes, 3.17 we have:

The FindCURL module learned to find CURL using the CURLConfig.cmake package configuration file generated by CURL's cmake buildsystem. It also gained a new CURL_NO_CURL_CMAKE option to disable this behavior.

[j-rivero]

I have an hypothesis: different versions of cmake are behaving differently in both machines. cmake 3.15.5 is in windows_mad while cmake 3.20.0 is in beefy. Checking the different release notes, 3.17 we have:

Let's see how this goes on beefy

[j-rivero]

Let's see how this goes on beefy

the change in 9cc7ea5 seems to be fixing the problem. pushed.

[scpeters]

Let's see how this goes on beefy

the change in 9cc7ea5 seems to be fixing the problem. pushed.

huh, this change was in the original PR, it must have been lost when resolving conflicts for the backport:

• https://github.com/osrf/gazebo/pull/3030/files#diff-ee282d0164c5074f3488942829f0a04b079af4db580b93456b323be2db465355R242