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. :)

Why so? On AIX as all other unix systems surely cmake will run its checks and
generate the output? Why would AIX out of all systems need a handmade
config-aix.h file stored?

> 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).

I don't agree with that reasoning, but I won't stress that since I'm not the
primary user of this anyway.

> - 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.

Wrong. The config.h files are always generated - they should've been
overwritten by cmake but weren't.

> - 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:

I see. I guess it's not a big problem in most cases but it could've just said
that as a warning or info or something...

> To build out-of-source, you can remove CMakeCache.txt and repeat the build.
> Or better, use a fresh clean source tree. :)

The source tree was clean and fresh.

> DS> Interestingly, if I remove src/config.h and lib/config.h before I run
> DS> "cmake . && make" it seems to work!?
>
> For CMake, overwriting an existing file with an auto-generated one is a
> no-no.

That's plain stupid and error-prone. I explicitly re-run cmake, then I want to
re-run the config phase and NATURALLY I want the updated results. Why else
would I run cmake in the first place?

> DS> BTW: how do I provide additional config options when I build with cmake?
> Like DS> "disable shared libs" and "enable debug mode" ?
>
> Uhm... I usually change CMakeLists.txt and rebuild. :)
> Or you can supply cmake with a '-D VARIABLE:TYPE=VALUE' construct on
> the command-line. Like this:
>
> cmake -D CMAKE_BUILD_TYPE:STRING=Debug ../curl-lib

First, changing CMakeLists.txt seems very awkward. That's like changing
configure.ac because you want to build differently. It's also versioned so
we'll get problems with accidental commits etc. Not to mention that it's not
very easy to understand how such an edit would be done.

Then, how would we know what -D CMAKE_BUILD_TYPE:STRING=Debug chunks to use?
With configure we get a configure --help output that lists most options. And
we have a docs/INSTALL text that describes lots of variations for different
build scenarios.

Oh. I now notice that /CMakeLists.txt has the version number hardcoded. That's
not a very good idea. It should fetch it from include/curl/curlver.h like the
configure script does...

-- 
  / daniel.haxx.se