Filipe Sousa wrote:

There is always ccmake and cmakeseup. Another option is to create a tool
called "cconfigure" for those who like configure scripts. That shouldn't
be to hard to implement. cconfigure --help would show the same options
as ccmake:
$ ./cconfigure --help
--cmake_build_type       Choose the type of build, options are: ...
--cmake_install_prefix   Install path prefix, prepended onto install

                         directories
--cmake_verbose_makefile If this value is on, makefiles will be
                         generated ...
[more options]

$ ./configure --cmake_build_type=release --cmake_install_prefix=/usr
  --cmake_verbose_make_file=true ~/projects/my_project
$ make
$ make install
  

"cconfigure" strikes me as a really bad naming choice.  People will forever be typing "configure" and wondering what's wrong.  You even did it yourself!

As for functionality: the point of an autoconf ./configure is that you don't need any special tool installed to run it.  If you have a Bourne shell, that's all you need.  Now, I suppose CMake could generate a ./configure script of sorts, that expects a Makefile on a Unixy system and doesn't need any additional tools to run.  Like, CMake itself isn't needed.  This would be entirely comparable to what autoconf actually does.  You use autoconf to generate ./configure, then you throw autoconf away during the actual build.  The problem is, I bet CMake can't do all of the detection stuff with just Bourne shell code.  It's going to need to interpret CMake code, which means you'll need to have CMake installed, which means you've defeated the purpose of not needing any special tool installed.  If the user has got CMake, might as well train them to type "cmake --whatever". 

Another issue is that an autoconf ./configure script typically relies on libtool.  You don't wanna go there.


Cheers,
Brandon Van Every

_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to