[CMake] What about...

[Brandon J. Van Every]

Thomas Zander wrote:
>
> 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
>   

You know there are CMakeSetup and CCMake... to quote Boromir, are you 
sure you do not suffer needlessly?


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

I think better policy is to have a ./configure that does nothing and 
tells the user this is a CMake build, not a ./configure build.  Also, 
you can't just claim the ./configure namespace gratuitously.  It is 
entirely valid to have both a CMake and a ./configure build of the same 
project.  Chicken is currently in that position now.  I'm working on 
killing ./configure, but I'm far from there yet.  The transition will 
take many months.  The new build has to prove itself to be 100% 
reliable, and then some, before old build goes away.

I think it's a very good idea to add "cmake --prefix=foo" because 1 
gazillion ./configure users would get warm squishy feelings from such 
functionality.  Although, it could become an Uncanny Valley problem.  
The closer you get to representing ./configure, the more complaints 
about how it's not ./configure!  So it may not be as good an idea as one 
would think.  It might be better to train people to use CMakeSetup and 
CCMake.  But that I admit is a GUI vs. command line battle.  Maybe it's 
advisable to beef up CMake's command line usability, if only for 
marketing purposes.


Cheers,
Brandon Van Every

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20060526/0c9091c0/attachment.htm