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

[William A. Hoffman]

At 07:55 PM 5/27/2006, Brandon J. Van Every wrote:
>[redirected to CMake-Promote, because my thoughts are primarily about marketing.]
>
>
>Thomas Zander wrote: 
>>
>>On Friday 26 May 2006 21:42, Brandon J. Van Every wrote:
>>  
>>>
>>>Another issue is that an autoconf ./configure script typically relies
>>>on libtool.  You don't wanna go there.
>>>    
>>
>>
>>Read my other mails in this thread please; its the NAME ONLY I suggested 
>>to use.
>>If the configure script is just 4kb and does nothing but provide a 
>>familiar front end to the cmake command (which I asserted earlier is not 
>>user friendly enough) then I'm happy.
>>Nobody was suggesting to go back to auto*
>
>I think stealing some command line options from ./configure is a good idea.  i.e. "cmake --prefix=/foo".  It would give people familiar with ./configure a warm squishy feeling.
>
>I don't know if distributing a shell script named "configure" that runs cmake is a good idea.  It's definitely a politically provocative move.  I'd be a bit worried about all the autoconf guys crying foul and there being some kind of backlash.  I'm not sure what kind of concrete damage it could do, but possibly, unwillingness to promote CMake, and uncooperativeness in getting it into distributions?  Will, what do you think?
>
>Perhaps a "boil the frog slowly" approach could work here:
>
>- first get CMake consistently in all the Linux distributions and etc.
>
>- second, implement the ./configure-style command line options in CMake, to the extent that they're applicable.  I think it's perfectly reasonable to have both --prefix and --cmake_install_prefix do the same thing.  "cmake --help" would show both options.  Refine the options according to user feedback.
>
>- once that foundation is laid, THEN go for the jugular of bumping off Autoconf ./configure scripts.  I think we'd be on morally higher ground if we're providing most of the options that the ./configure crowd wants.
>
>Of course, if cmake is not installed, the ./configure script would complain and point out where to get it.  Especially, if Linux distributions are well in order, it could point out some methods for getting cmake.  I think some distros have command lines you can type to get stuff.  The ./configure script could fire those off.  Command could be something like "./configure --get_cmake".  If someone runs ./configure and cmake isn't available, it could tell you to type "./configure --get_cmake".

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]

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.

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.

-Bill