On Wed, 15 Apr 2009, Sukender wrote:

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

So using such a separate tool is basically the way to change build options?
How is the newly selected options stored then? Does the "CMake GUI" replace
the cmake command line tool or is that only used to edit options?

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

Why would we need to do that? src/config.h and lib/config.h are both generated
by the build system. It makes perfect sense to use the same name, no matter
who generates those files.

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

I would expect cmake to do that so I'd vote for it. But as mentioned before,
I'm not the prime target for this work so quite possibly my ideas of how this
should work are not the most important.

BTW, some other things that seems to still be missing when building (lib)curl
with cmake:

  - curl-config
  - libcurl.pc
  - make install doesn't exist/work
  - 'make' always do "built target ..." for 20+ targets even when nothing is
    changed

-- 
  / daniel.haxx.se