[poppler] RFC: cmake buildsystem

[Albert Astals Cid]

A Dimecres 19 Desembre 2007, Pino Toscano va escriure:
> Hi,
>
> as we recently gave new fresh air to out VCS (cvs → git), what about some
> to the build system? ;)
> So, this is a proposal to have cmake as at least secondary build system for
> poppler.
>
> Here there are some of the advantage using cmake in poppler can bring:
> - improve portability (ok, libtool is portable as well), cmake is a
> generator, so you can generate usual Makefile's, KDevelop3 projects and
> MSVC projects (so bye bye to custom Makefile for it)
> - much faster configuration phase, and compilation (without libtool)
> - files are compiled only once (and not twice - or three times for Qt
> frontends! - )
> - (not really important, but still) differentate between xpdf and our
> buildsystem, so there's no potential conflict when sync'ing next time(s)
> with xpdf
> - nicer output ;)
> Some of its disadvantages:
> - a more verbose syntax, and less tied to the shell
> - some "automagics" less
>
> Moreover, the new buildsystem for poppler includes a small refactor of the
> unit tests compilation, so you can selective enable/disable the Qt3, Qt4
> and GLib unit tests.
>
> How to test:
> I suggest to do a clean checkout of poppler, and to unpack the attached
> archive from the top-level. Then, create and use a separate build dir:
> $ mkdir build
> $ cd build
> $ cmake [options] ..
> $ make
>
> The cmake options have to be specified in a different way than usual *nix
> applications. The syntax is basically -Dkey=value. For example:
> - -DCMAKE_INSTALL_PREFIX=/prefix -- to set the installation prefix
> - -DBUILD_GTK_TESTS=ON -- to enable the compilation of the GTK+ unit tests
> and so on; you can find a list of the boolean options (that can have the
> value of ON/OFF/on/off) in the top of the root CMakeLists.txt, specified by
> the commands options().
>
> All of this was successfully tested on GNU/Linux, and popplercore/Qt4
> frontends on mingw/win32.
>
> Feedback? Thoughts?

Just removing the burden of having to manually write MSVC projects is a good 
reason for me.

My suggestion would be to import it once you have all the missing bits done 
and let the build systems coexist so people can get the chance to use both 
and see which one is better for them, if noone finds a problem with cmake we 
can talk of a total switch later.

Albert