#1098 CMake fails with sources from github

[theret]

OS: any
CMake: any
cURL: current development sources from github

CMake fails with:

CMake Error at src/CMakeLists.txt:18 (add_executable):
Cannot find source file:

config-win32.h

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

The failing line is:

${CMAKE_SOURCE_DIR}/src/CMakeLists.txt:18:
add_executable(
${EXE_NAME}
${curl_SOURCES}
)

curl_SOURCES is defined in ${CMAKE_BINARY_DIR}/src/Makefile.inc.cmake:
SET(CURL_HFILES hugehelp.h setup.h config-win32.h config-mac.h [...]
SET(curl_SOURCES ${CURL_CFILES} ${CURLX_ONES} ${CURL_HFILES})

The problem is that add_executable() needs the full path to all source files outside the current dir. But config-win32.h is in ${CMAKE_SOURCE_DIR}/lib not in the current dir (src).

Solution:

Set the full path ${CMAKE_SOURCE_DIR}/lib/config-win32.h in Makefile.inc.cmake, e.g.:

SET(CURL_HFILES hugehelp.h setup.h ${CMAKE_SOURCE_DIR}/lib/config-win32.h config-mac.h [...]

[Dan Fandrich]

Have you tried one of the daily tarballs instead of the git repository? The git repo needs some massaging of files to make it ready for building, and IIRC some of the config files are copied during the massaging that happens.

[theret]

I can confirm it works with the daily tarball. Do you apply a certain script to do the "massaging"? Is there a way for me to reproduce that?

[Daniel Stenberg]

Yes, you need a script to "massage" it after a git checkout, as is detailed in the GIT-INFO file.

There's also scripts run when the tarballs are made so we should make sure what you need isn't made only then.

[theret]

1. OK, I looked at GIT-INFO but the scripts mentioned therein are not relevant for cmake. They are autotools related. I don't have autotools (e.g. windows) and hence want to build curl with cmake. So what do I have to do exactly before I can do that? Which script does the "massaging"?

2. As a sidenote: people who use cmake for building are potentially unable to run shell scripts to do the massaging. so ideally curl should take care of creating necessary support files itself with cmake scripts.

[Daniel Stenberg]

The info is already in GIT-INFO and yes, it is autotool-centric.

I don't have any solution for cmake, and I'm not able to produce any. If you can help us with that then I'm interested.

To me, cmake support is a game we are doomed to lose and I am leaning towards just completely ripping it out again.

[theret]

I would volunteer to help but I need more information from you to do so:

1. I am unable to figure out how exactly you create the daily tarball from the git repository. Obviously it is something hidden and unmentioned in GIT-INFO. Running the scripts that GIT-INFO suggests does not result in a tree that is equal to the tarball.

2. I am surprised to hear that you still hold on to the aging autotools since everybody is moving away from it. I thought you were transitioning to cmake not away from it. I myself just ripped autotools out of a big project because it is too complicated and difficult to maintain. And last but not least because the Windows users complain that autotools is useless for them. The effort I put in it paid off a lot already. Cmake does not depend on shell scripts in the configuration and build process which makes it actually portable. Since curl is developed on many platforms cmake would be the ideal build system for it. In this case I pretty much agree with the view of KDE developer Alexander Neundorf (http://lwn.net/Articles/188693/).

3. I agree that maintaining two different build systems is tedious. But since you already have two working an one them is cmake then given the list of its supported platforms I don't understand why you wouldn't want to kick out autotools instead.

[Daniel Stenberg]

1. We run 'maketgz' to build tarballs/releases.

2. cmake is less good for us primarily because of two reasons: firstly there's just nobody around who knows cmake and who contributes fixes to the cmake build scripts while all seasoned hackers already are familiar with autotools and have learned how to patch and work with them decently. Just look at how we've had cmake support for almost three years now and we really don't have contributions that fix the build and you can easily find this amount of serious flaws. The second reason would be that cmake just isn't present in most people's (legacy) *nix systems which makes it a rather annoying extra dependency.

I don't see how opinions from someone maintaining a thing such as KDE which is FAR less portable than curl is would change my view.

3. If I would kick one out, I'd kick out cmake because the autotools based build we have is complete and up-to-date, while the cmake one is a long way from that. And because I know autotools and not cmake. I accepted to add the cmake build option (after much debate over the years) primarily because lots of people claimed it would be as good as you say and I thought it was worth giving it a shot. I've not been convinced about its greatness since then. It hasn't done much harm either of course, since I honestly believe hardly anyone uses this build option...

[Daniel Stenberg]

This bug is reported in an older version and seems (or is possible) to have been corrected in a more recent version.

If you can please upgrade and try it again with the latest version, it would help a lot!

[Daniel Stenberg]

bah, please ignore that last comment - it was not the one I meant (I used a response from a drop-down list and obviously did wrong)