2007/8/10, gga <[EMAIL PROTECTED]>: > Brandon Van Every wrote: > > On 8/8/07, gga <[EMAIL PROTECTED]> wrote: > >> I know I can pass -D symbols to cmake to modify its behavior and that > >> windows also has its ugly CmakeSetup gui. > > > > "Ugly?" Geez, what are you, a candidate for Windows Aero or something? > > > > No, I am a candidate for something that works and ccmake/cmakesetup does > not work well. Don't confuse eye candy with functionality. When I mean > ugly, I mean there's basic functionality missing from ccmake/cmakesetup.
I think this is clearer :)) And the list you gave afterwards is interesting, I'll give my point of view on each item below. > This, unfortunately, clearly rules cmake from being a good candidate to > replace autotools, even if its core is much better. > > The problems with the current approach are: > - Variables for configuration are unknown to the user unless he > digs into all of the cmake modules used. > Compare this to running any autotools project: > ./configure > (you get full help for all the libs and options you can use). I think there is a confusion here. ./configure does not give you "full help" unless the writer of the configure scripts did it using --enable-xx or --with-xxx. I may well write ugly configure.ac (in fact I did it in the past) which won't help you AT ALL, even if the script will do its jobs perfectly. May be CMake user should be taught to use more OPTION in order to give more informations (using OPTION description) to the user. > > ./cmake > (I get cmake's documentation, nothing about my project) > ../ccmake (on a clean project) > (Nothing) You are right this is annoying, I would very much like cmake / ccmake tell me something about my project if called in a build tree or a pristine source tree. They may list the project name and possibly the list of available OPTION with desc line. Something that mimics the behavior of ant -p (with the added verbose mode ant -v -p, which gives you even more informations) for compatibility reason I would avoid doing this when cmake is invoked without option but telling the user that a cmake -p will do the job. > > - ccmake/cmakesetup list variables in the cache only. > If you are building out of source (as I do), the > CMakeCache.txt and the CMakeLists.txt are in > different directories, which again can be confusing to a user. I think a CMake user must be taught to understand out-of-source build there nothing CMake can (implicitly) do about this. However CMake supports in-source build too, such that "young" CMake user may continue to do in-source build. As a side note autotools does support out-of-source build but how many "occasional" ./configure user out there do use out of source build with autotools? Moreover I was pretty disappointed to discover that autoconf+automake do generates "some" files in my source tree even if I do out of source build (missing, install-sh etc...) This is a real annoyance because when you use the same source tree to build on different hosts using different version set of autoconf/automake sometimes you get message like this: ============== make distclean cd ../CERTI && /bin/sh /udd/deri/enoulard/workspace/CERTI/missing --run automake-1.8 --gnu /udd/deri/enoulard/workspace/CERTI/missing: line 52: automake-1.8: command not found WARNING: `automake-1.8' is missing on your system. You should only need it if you modified `Makefile.am', `acinclude.m4' or `configure.in'. You might want to install the `Automake' and `Perl' packages. Grab them from any GNU archive site. cd . && /bin/sh ./config.status Makefile =============== even if the current machine a a perfectly running automake-1.10 !! > - As ccmake/cmakesetup rely on cached variables, a user running > the project for the first time will not get ANY variables > when he runs ccmake. He HAS to run cmake first. I agree this is really puzzling, thoses tools should "at least" show you OPTION with associated desc lines. However this is not as easy as it seems because you may well have "optional" OPTION, i.e. which are OPTION defined if some other things discovered at CMake run time may enable/disable. In fact the only mean to know what option are available is to run CMake once... > - ccmake/cmakesetup lists pretty much ALL variables. > Scary as hell to a user not familiar with your project and > tedious to find the variable you need if you do know the > project. > - AFAIK, -D does not allow DISABLING options, like --disable-X > does. When using OPTION macro, -DOPTNAME:BOOL=TRUE enables and -DOPTNAME:BOOL=FALSE disables Note that effectively DISABLING something depends on the CMakeLists.txt writer just as when you use --disable-xxx using autotools it's up to the configure.ac writer to do something with the value set by ac_arg_enable macro. Again I may write a configure.ac which won't even take care of its --enable-xxxx option. > The FindXXX modules will take over and find the library > even if I told it to disable some library. Find modules do not "take over" the CMakeLists.txt writer is responsible for calling or NOT calling FIND_PACKAGE(whatever) depending on OPTION value selected by user. It is "just the same" behavior as AC_C_xxx macros for example. it is up to the configure.ac writer to call them when appropriate. For example if you define your --enable-X-support option you should "normally" conditionally call AC_PATH_X but I promise you that autotools won't help you in not calling AC_PATH_X when --disable-X-support is called. YOU should take care of that. I think your remarks are illustrating the fact that CMake users do not usually follow "common rules" for writing their CMakeLists.txt because there is none, whereas you have many indications in the autoconf manual. (http://www.gnu.org/software/autoconf/manual/) Since CMake does not enforce you the way to go you end-up with an apparently less consistent behavior than the ones you usually obtains with autotools. I think consistency and most of the CMake deficiencies (but the "available" OPTION list ) you have identified are due to CMake usage and not CMake itself. -- Erk _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake