[CMake] What about...

[William A. Hoffman]

At 12:13 PM 5/26/2006, Thomas Zander wrote:
>On Friday 26 May 2006 17:55, you wrote:
>> >A 'configure' script generator that will just convert between the
>> > (good old) configure and the cmake foo.  Makes it actually possible
>> > to discover what features there are without consulting online
>> > documentation ;)
>>
>> I am not sure about what you want here.  
>> Do you want something that will convert a configure script into cmake
>> files? Do you want to convert cmake files into a configure script?
>>  What is the goal with this question?
>
>I have helped a set of people on irc to get started with koffice compiling 
>using cmake. They all had a lot of problems with the arcane variables 
>like the CMAKE_INSTALL_PREFIX and most people find that D in front a bit 
>weird a well.
>
>So; instead of letting the user (not only a developer!!) type
> cmake ../../project -DCMAKE_INSTALL_PREFIX=$KDEDIR
>there would be a command line tool (which I want to call configure, I 
>don't care if its shell script or perl or whatever) and that tool would 
>parse:
>        ./configure --prefix=foo
>and execute the cmake equivalent that I typed above.
>
>Again; this is all focussed on making cmake more usable for the KDE 
>community; but I guess a lot of cmake users will benefit from it as well.
>You have to remember that there are a lot of end users downloading the 
>sources and I can't in all honesty tell them its something better if they 
>have to type the above cmake PREFIX thing instead of using the configure 
>thing we had before.
>
>Hope that explains it better :)

Sure, that does explain it better.   And to be honest, the command line
was not how cmake was intended to be used.   ccmake, cmake -i, or CMakeSetup
on windows provides a much better user experience.   Part of the problem
is the ability of a cmake run to create new options each time an option is changed.
It is more of an iterative process.   Before cmake is run on a project, there
is really no way to tell all of the options.  Even standard options like
CMAKE_INSTALL_PREFIX could have been changed by the project.

Something like this:

set(MYPROJECT_INSTALL_PREFIX /myinstall/location CACHE PATH)
set(CMAKE_INSTALL_PREFIX ${MYPROJECT_INSTALL_PREFIX} CACHE INTERNAL)

In which case changing CMAKE_INSTALL_PREFIX on the command line will not
do anything, but what you really need to change MYPROJECT_INSTALL_PREFIX.
All of this works with ccmake or CMakeSetup, or even cmake -i.   But,
you can also have the case that by turning on a variable, it creates more
variables.   

option(USE_FOOBAR "use the foobar package" FALSE)
if(USE_FOOBAR)
   option(USE_FOOBAR_SUBTASK "use the foobar subtask option" FALSE)
endif(USE_FOOBAR)

Until USE_FOOBAR is TRUE, the option USE_FOOBAR_SUBTASK is not even an option.

Maybe a better way to tell folks to use cmake, is to use ccmake.
I agree that the -DFOO=VALUE is awkward, and I never use it myself, prefering
ccmake or CMakeSeutp.

I use make edit_cache most of the time.

-Bill