Re: [Liborigin-devel] [PATCH 1/3] Add install target and remove linking against Qt libs

[Knut F. <Knu...@gm...>]

[2010-11-03 13:38] Miquel Garriga <gbm...@gm...>:
> What I dislike of CMake is:
>  a) There is no easy way of removing the CMake generated files (like
> "make distclean"
> does for qmake), other that creating a "build" subdir and start cmake
> from there.

Yes, that would be the preferred solution with CMake (for good reasons, I'd say[1]).

> That solution is (almost equivalent) to use a subdir for opj2dat.

Why? Subdirs aren't evil if used with some consideration. I wouldn't even say a subdir for opj2dat would be totally out of the question, although a subdir for a single source 
file is a bit suboptimal due to the (mental) overhead it creates. Having a separate directory for output files makes perfect sense to me, also since this keeps the source 
directory free from non-source files (and thus easier to understand) at all times.

Besides, if you insist on in-source builds, you can use Git to determine which files were added (e.g. using "git status -s") and possibly even write a small script which removes 
them.

>  b) There is no easy way to see what the make command will do.
> The  usual  "make -n" command only shows a series of CMake related
> commands.

Admittedly the "make -n" output with CMake isn't as nice as with qmake, but it shows not *only* CMake-related commands (at least on my system). A small script munging the "make 
-n" output a bit may help. Try something like

make -n | awk '/cmake_echo|cmake_progress/ {next} /cmake_link_script/ {getline < $4} //'

> Maybe in the long run  handmade  Makefile(s) will be the  simplest
> solution.

I hope not. Having to maintain separate Makefiles for all sorts of different platforms is annoying and error-prone.

By the way, we already did have this approach in liborigin1 (last commit was dba976c); not suprprisingly, the implemented functionality varied widely between the relatively 
complete Linux Makefile (with lots of settings, install and uninstall targets) and the Solaris one (which only supported rudimentary opj2dat and clean targets). With a cross-
platform build tool, all platforms get the same set of features. Not to mention none gets outdated, e.g. if the set of source files changes.

Just to be clear on this point, I don't think CMake is anywhere near perfect (although I have different gripes with it than you). I just think it's the least undesirable of the 
available options.


Knut

[1] http://www.cmake.org/Wiki/CMake_FAQ#CMake_does_not_generate_a_.22make_distclean.22_target._Why.3F