Bug 132075

Two things can be done:
1) write a better Qt4 based version instead of the curses-based ccmake, and feel free to add a lot of more features to it
2) it is planned to add more "comfortable" command line switches to cmake, Andy has it on its TODO.

Next to these 2 solutions there is a 3th solution that works equally well; to supply an already learned interface and let it wrap cmake itself.  Kind of like how users get to use 'make' and not call cmake itself.

So, I think KDE should supply a 'configure' script (in perl or whatever) which calls cmake itself.
If you follow suggestion 2) the end user still needs this wrapper script, in fact.

I think it shouldn't be hidden from the user that he isn't using autotools, otherwise he will expect more and more features from it.

Other core developers have the same opinion:
http://mail.kde.org/pipermail/kde-buildsystem/2006-July/003093.html
http://mail.kde.org/pipermail/kde-buildsystem/2006-July/003098.html

Alex

Created attachment 21803 [details]
A configure wrapper that generates a CMake command

This shell script takes Autohell command-line options and generates CMake
options from them.

I only want to aggree to make cmake much more *NIX user friendly. Maybe 90% of open software packages use autotools and software-from-scratch-lovers don't like to have for every package a new "revolutionary" software compilation method. (The ugly boost installation method is frustrating enough!!!) I don't know what the real benefits of cmake is for Unix users but for admins I think it is much more inconvienient as autotools. So, PLEASE find a solution for simple-structured-admin.

cmake should receive at least some compatibility options like:
--prefix=/path/to/whatelse 
--enable-<feature> 
--libdir=<path>
--sysconfdir=<path>

I think these feature should be added URGENTLY BEFORE KDE4 will be released and I believe it should not be that difficult.

A cmake configuration example like

mkdir build ; cd build
cmake --prefix=/opt/kde4 --enable-final ..  

will increase dramatically the hapiness level of simple structured admins like me and maybe for some other KDE-from-scratch-admins. 

Honenstly speaking - I'm not willing to spent my spare time to test KDE4 if you guys make the compilation life for me sooo inconvenient. Maybe other testers out there aggree with me. KDE4 is such a good project that it need much more interested and ambitioned testers.

Some comments:

-this is not the cmake bug tracker, it is for reporting bugs in the cmake files for KDE, please file feature requests for cmake in the cmake bug tracker: http://www.cmake.org/Bug

-we will need some script called "configure", which either calls cmake or which tells users how they should call cmake and where to find documentation (the attached script looks not bad so far)

-we should not hide that we are not using autotools, we are using a new tool (cmake), users need to know this, otherwise they will expect autotools-like behaviour (which is not a primary goal of cmake)

-do you know about "make edit_cache" or ccmake ? Using these you get a curses GUI where you can adjust variables, i.e. it lists the available variables. a Qt GUI would be nice.

-there should be docs on techbase.kde.org

For the beginning:

"cmake -DCMAKE_INSTALL_PREFIX <srcdir>" should be good enough.

Alex

- aggreed, this is not the cmake bug tracker, BUT cmake guys offered the kde people support and if you guys tell them YOU want that, then the certinity of the realization of an adopted/unix-user-streamlined cmake interface will increase significantly. YOU, the KDE-people, are the more powerfull group influencing cmake guys ;-)

- if you know the options of cmake, -DCMAKE_<whatelsemysteriousoptions> it is "good enough" BUT the questions is, how many KDE testers do you want to have. I think you should grab as many testers as possible. If you give every new car a new steering mechanism, be sure there will be significant more accidents on the streets because users have first to learn steering i.e. with sticks intead of a wheel. If you offer simple-structured-drivers a plugin for a wheel AND for a stick and the driver decides, what he likes more AND you will see MORE drivers on the streets! And I'wd assume that's what cmake and KDE guys like to see?

- technically: I don't believe it is a big task to streamline cmake offering

 --prefix=/path/to/whatelse 
 --enable-<feature> 
 --libdir=<path> 
 --sysconfdir=<path> 

On Thursday 01 November 2007 10:29:24 Alexander Neundorf wrote:
> -this is not the cmake bug tracker, it is for reporting bugs in the
> cmake files for KDE, please file feature requests for cmake in the
> cmake bug tracker: http://www.cmake.org/Bug


That sounds a bit odd coming from the guy that asked me file this bug on 
the kde bugtracker.

> -we should not hide that we are not using autotools, we are using a new
> tool (cmake), users need to know this, otherwise they will expect
> autotools-like behaviour (which is not a primary goal of cmake)


You seem to misunderstand reinhards point then, his suggestion means it is 
no longer about making it more like auto*. It is now about using a 
standard in argument handling that has been perfected over some 30 years.
The Unix type of argument handling is what people know because 99% of the 
command line apps follow that standard.  Just because automake uses that 
too should not be an argument against following the standard.

I committed a configure script (based on the attachement, but many things removed) to kdelibs, and cmake cvs now has the beginnings of a Qt based GUI.

Alex

Well, this is only the second best solution (I'd call it workaround) If cmake has really advantages compared to autotools I don't want a graphical gui to configure cmake. I (and maybe some other unix friends) prefer a simple console based ./configure-similar interface  which I can handle through a low speed connection and firefalls.

Again: the best solution is to extend cmake with compatibility features for autotools. Why should that be sooo unimpossible - ok, this is the wrong auditorium - BUT you (KDE-people) are one big "cmake-customer".

Adding support for some way to get easier/shorter command line arguments for cmake is on the TODO (I'm not sure if it's in the cmake bugtracker or just my personal TODO).
First step would be to use the command argument parser in CMake/Source/kwsys/ in CMake itself. Patches are welcome :-)

Anyway, having this as a feature request in the *KDE* bug tracker doesn't make sense.

Alex