[CMake-Promote] a ./configure shell script stub

[Brandon J. Van Every]

William A. Hoffman wrote:
>
> So, it would be not too hard to create a common list of options, but the problem
> is that cmake must be run before you even know what all the options are.  Maybe it would
> be enough to do the same thing that the CMake bootstrap script does:
>
>  --prefix=PREFIX         install files in tree rooted at PREFIX
>                           [${cmake_default_prefix}]
>   --datadir=DIR           install data files in PREFIX/DIR
>                           [/share/CMake]
>   --docdir=DIR            install documentation files in PREFIX/DIR
>                           [/doc/CMake]
>   --mandir=DIR            install man pages files in PREFIX/DIR/manN
>                           [/man]
>   

Before breaking it down at that fine a grain, with different data, doc, 
and man directories, I have to ask: do the ./configure people do this on 
a regular basis?  Or are those just tweaky options they have for the 
sake of completeness?  I've never once specified a data, doc, or man dir 
separately in 14 years of running ./configure scripts.  I think the vast 
majority of people just want the thing to work and be done with it.  
 From a marketing standpoint, the idea is to give the ./configure crowd 
a warm squishy feeling, that the most commonly used options are readily 
available and work as you'd expect.  It doesn't have to completely 
reimplement all ./configure options.

I will say that aesthetically speaking, the output of "./configure 
--help" is entirely too long.  The only options I ever use are:

  --help
  --prefix=/my/install/directory
  --with-weirdlibrary or --no-weirdlibrary (always project specific)
  --totally-custom-project-specific-option

In the past I've sometimes screwed with environment variables to get 
things to work.  But it's all kind of futzy and error prone and results 
in repeated steps upon a rebuild.  You can define things on the 
./configure command line.  You can define things in the environment.  Or 
you can edit the Makefile; that's often the path of least resistance 
when things are fouled.  ./configure lists the relevant environment 
variables, but I'm not inclined to aid and abet a hapless user in such 
tweaking.  It will only cause him pain and suffering.  He should just 
run CMakeSetup.

> These would translate to CMake variables in the cache.   Another option, might
> be to have an options file for a project.
>
> CMakeCommandLineOptions.cmake
> add_cmake_option("--prefix", CMAKE_INSTALL_PREFIX, "docs for install")
>
> If you ran:
> cmake --help ../source 
> It would print out the command line options for the project.
>   

"cmake --help" should tell the user how to get project-specific help.  
People will not remember a bunch of options; they will remember to type 
--help, and then do whatever it says to do.  I also think if someone 
types "cmake --help" in a directory with CMakeLists.txt, then CMake 
should just list the project-specifc help along with the general help.  
By comparison, a ./configure script has plenty of boilerplate that's the 
same for every project.  Also if we're in an out-of-build directory, 
"cmake --help" should deduce where the source directory is so we don't 
have to specify it.

> The real problem is that cmakelist code can do anything and add any
> variables.  Until cmake is run on the project, there is no way to tell
> what the potential command line options are.   This would allow a way
> for a project to tell cmake what the options are, but the could be inconsistent
> with the project.   It would be easy to make an option like CMAKE_INSTLAL_PREFIX
> not do anything for a particular project.
>   

True in theory.  In practice, how many CMake projects are really 
renaming the installation directory to Kalamazoo?  I'll wager that most 
CMake projects are simple.  This a marketing problem; if most projects 
do what's expected, then CMake isn't sullied by the few projects that do 
a totally custom powerjob.  Those projects are going to have READMEs and 
be big and complex with all sorts of special things you have to do anyways.


Cheers,
Brandon Van Every

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-promote/attachments/20060528/3784baa4/attachment.html>