Hi Daniel,

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

Of course not! The Cmake GUI actually *does* the same thing as a "manual" edition. And Tetetest said something wrong: you should NEVER change CMakeLists.txt to tweak options; however, you may modify CMakeCache.txt as you wish. The "normal" way of configuring with CMake (without the GUI) is:
1. Invoke CMake, potentially with some options on the command line (as Tetetest said). CMake will create (or update) CMakeCache.txt.
2. If something is to be changed (option, path, etc.), modify this cache with a text editor and go to "1."

If, for any reason, the makefiles could not be generated, then you should modify the cache according to the CMake output (and re-configure). This is also a normal way to work with CMake, even if it may reflect you got something wrong in your scripts. But if you wish to create a script that forces the user to tweak things, that's possible.

And with the GUI:
1. Configure
2. Change any options you wish, and re-configure until everything is ok
3. Generate (= effectively writes the makefiles to disk)

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

I agree the CMake scripts should delete the config.h on the first run.
However I'm wondering if CMake doesn't actually overwrite config.h when an option changes...

> 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

There are surely many things to do. Thanks for reporting.
BTW, what are curl-config and libcurl.pc? (Sorry if that's obvious, but I won't have a look into that before a few days I guess).
Sorry I can't work much on it right now. I'll do ASAP.

-- 
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/