cURL / Mailing Lists / curl-library / Single Mail


Re: cmake

From: Sukender <>
Date: Wed, 15 Apr 2009 23:08:52 +0200

Tetetest wrote:
> Hello Daniel,
> Wednesday, April 15, 2009, 5:06:35 PM, you wrote:
> DS> On Wed, 15 Apr 2009, Tetetest wrote:
>>> DS> 2. What's the purpose of CMake/Platforms/config-aix.h ?
>>> This is a legacy file that goes with CMake itself. I didn't check if it is
>>> really needed.
> DS> So we remove that and see if things go boom?
> On AIX, they will more or less certainly go boom. :)
> Other platforms are more or less certainly not affected by this file.
>>> DS> /home/daniel/src/curl-alt/lib/config.h:375:1: warning: "HAVE_LIBZ" redefined
>>> Basically, CMake builds must use generated config.h file.
> DS> But why does it use leftovers from before? That seems like a bug!
> Those 'leftovers' are not used by normal, out-of-source CMake build.
> The only situation they get in your way is when you build in-source
> (which is possible with CMake, albeit strongly NOT recommended).
> The consequences of in-source builds include:
> - auto-generated files may not get updated properly (especially if the
> file already exists in the source tree). This is exactly what
> happened with you.
> - once you have attempted to build in-source, CMake creates cache
> files that instructs CMake to do in-source builds even if you try to
> build it out-of-source. This is exactly what happened with you
> afterwards:
> DS> Clearly something is missing as that doesn't work for me:
> DS> $ cmake --version
> DS> cmake version 2.6-patch 3
> DS> $ mkdir curl-cmake
> DS> $ cd curl-cmake
> DS> $ cmake ../curl-alt/
> DS> -- Configuring done
> DS> -- Generating done
> DS> -- Build files have been written to: /home/daniel/src/curl-alt
> DS> $ make
> DS> make: *** No targets specified and no makefile found. Stop.
> CMake sees CMakeCache files in your source tree, understands that it
> must perform an in-source build, and generates Makefiles right into
> the source tree.
> To build out-of-source, you can remove CMakeCache.txt and repeat the
> build. Or better, use a fresh clean source tree. :)
>>> DS> Linking C executable curl
>>> DS> CMakeFiles/curl.dir/curlutil.c.o: In function `cutil_tvnow':
>>> DS> curlutil.c:(.text+0x15): undefined reference to `clock_gettime'
>>> DS> collect2: ld returned 1 exit status
>>> Again, it looks like your build catches the wrong config.h :)
> DS> Not exactly, that's the link phase that fails so a header file won't be used.
> DS> It is a lack of use/detect of the correct lib, librt in this case. But they
> DS> certainly seem related:
> DS> Interestingly, if I remove src/config.h and lib/config.h before I run "cmake .
> DS> && make" it seems to work!?
> For CMake, overwriting an existing file with an auto-generated one is
> a no-no. When you remove the file, CMake is happy to generate a new
> one. That's why in-source builds are not recommended for CMake: you
> cannot be sure that all files are generated properly.

Hi Daniel and Tetetest,

I'd like to add a few comments:
You may say I'm a lazy M$-user, but I find using the CMake GUI quite convenient for some uses... I did not find it installed by the latest Fedora CMake package, so I had to download from the website & install. And you have a "Clear cache" option (I bet it also exists on the command line)... the one you *MUST* always call when you're having trouble, or when you change your build directory ;)

About out-of-source builds, I don't totally agree. For me, out-of-source builds are better in the way you just have to delete a directory to clean up. But in-source builds should work as out-of-source buils, and should not interfere with existing files. So what? May we rename the config.h to config-cmake.h for CMake? I guess that's a bad idea since we'd have to change the source. I guess here the build actually does *not* interfere with existing files, but with the existing build system. Am I wrong? Any idea to work around that? Force the CMake script to delete config.h?

BTW, I finally got my new laptop. While it'll be fully operational, I'll certainly test CMake scripts under Fedora 10 (or 11 when no more in beta), and under WinXP.

PVLE - Lightweight cross-platform game engine -
Received on 2009-04-15