FallingStar wrote: |
---|
As a side question how do you figured out the steps above? |
After spending many weeks trying to compile other people's code, I've learned where to look. I also use CMake with my own projects. Most projects that have a CMakeLists.txt will build fine, in my experience. Some, like this one, just need a little help.
For curl, I tried building without
-DBUILD_TESTING=OFF and it encountered an error about a subdirectory not having a CMakeLists.txt file, so I opened the main CMakeLists.txt and looked for all the add_subdirectory commands, found the one that was causing the issue, and noticed that it was conditional on
BUILD_TESTING, so I just turned it off :p
For curlpp, I had a lot of trouble - it uses CMake's built in FindCURL module which hasn't been updated in years unlike other find modules, so you have to pass both the include directory AND the path to the lib. I just looked at the source code in CMake's GitHub repository to find out the names of the variables I needed to set, but the naming convention is present in most find modules so I could have guessed.
That got it to configure, now I needed to build it - whenever it got to a linking step, it kept complaining about curlpp's own symbols being unresolved. Scrolling back up the build log I notice a lot of warnings about dllimport attributes, and I know what the issue is - typically libraries use a define to control whether the code is being exported to the DLL or imported from it so the same headers can be used for both compilation and user projects. I looked through the source code and found this:
https://github.com/jpbarrette/curlpp/blob/4632e2d58aa37d435dba071692668db146501bce/include/curlpp/internal/buildconfig.h#L31-L51
So I knew to fix it I had to set
BUILDING_CURLPP during compilation. Fun fact, all the other project files (e.g. visual studio) do seem to properly set this flag, so they only forgot in the CMake scripts.
After that it mostly worked and then those two examples I told you to comment out failed to build, so I just hand-edited the CMakeLists.txt in that case to not build them - they're just examples and you can read their source and fix the portability issues yourself I assume. Generally though I try to avoid editing files by hand at all costs - in this case it was necessary.
Welcome to Windows programming, where developers often only test their code on *nix and say that it should work 'in theory' on Windows. Sometimes you have to apply elbow grease ;)