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 |
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
