CMake vs autotools: poppler

Poppler has a CMake ebuild now. Given how poppler is used it seems to me quite a bad move, poppler is small and used in system that may not have cmake already installed.

I run some numbers when wesnoth moved to cmake and claimed that it took about twice for me to build wesnoth+cmake on a phenom and building wesnoth alone took nearly the same time. Later a friend of mine wanted to play with me with wesnoth and given her pc is a _bit_ old, took ages to build an up to date wesnoth, about twice the time you may consider bearable thanks to the cmake switch.

Let’s see what means switching poppler to CMake now, after the previous post I got some news of nice improvements, hopefully it improved even more while I wasn’t watching.

Now some numbers:

I have my system in need to update poppler, still the phenom I used the other time, it is doing nothing right now:

cat /proc/cpuinfo | grep model_name
model name : AMD Phenom(tm) 9500 Quad-Core Processor

first: I need cmake

cmake ebuild tell me that I need xmlrpc-c with curl and curl with a kind of ssl support. I don’t see the point of having an xmlrpc library and two xml libraries for a make system, well let’s set the right useflags and trigger emerge cmake

time says

real 8m9.854s
user 13m8.121s
sys 3m7.664s

qlop on the cut down emerge.log says

domino ~ # qlop -t cmake -f mylog
cmake: 207 seconds average for 1 merges
domino ~ # qlop -t curl -f mylog
curl: 233 seconds average for 1 merges
domino ~ # qlop -t xmlrpc-c -f mylog
xmlrpc-c: 40 seconds average for 1 merges

So cmake is taking about the time of curl and it’s indeed faster to build that before (it alone), still autoconf+autotools take less than 60s here, and if we factor in the deps then we still have large margin for improvements (please make xmlrpc-c, curl, libxml and expat optional)

app-text/poppler

takes about 37-40 seconds

Hacking a bare ebuild w/out touching poppler configure.ac makes it take about 60-66 seconds

So if you are having cmake already installed this poppler ebuild is _quite_ an huge improvement. If you are wondering why that happens I could guess that given that poppler is quite small the cmake quicker configure step gives this large boost, probably not having libtool in the way helps as well.

To sum up:
– the cmake poppler builds quite faster than autotools poppler.
– CMake improved a lot its build time, yet is largely bloated and could enjoy a trim.
– Poppler configure.ac probably could be improved to be in line with the cmake times.

9 thoughts on “CMake vs autotools: poppler”

  1. Problem is that the glib-side developers of poppler don’t use CMake, so they don’t update its build files when they update the autotools’ ones.

  2. Well the autotools could enjoy some overhauls since they spend some more time checking in a bit deep ways that stuff work (compiling&running tests) and I like better having autotools in the ebuild, but probably I would enjoy having it as clean as the cmake one.

  3. Sun Jan 24 19:33:24 2010 >>> dev-util/cmake-2.8.0-r1
    merge time: 43 seconds.

    Sun Jan 24 17:50:49 2010 >>> app-text/poppler-0.12.3
    merge time: 37 seconds.

    Fri Nov 6 14:17:24 2009 >>> net-misc/curl-7.19.7
    merge time: 1 minute and 49 seconds.

    Mon May 11 00:14:39 2009 >>> dev-libs/xmlrpc-c-1.18.02
    merge time: 26 seconds.

    SUM:
    3.5 minutes

    Machine
    model name : AMD Phenom(tm) 9750 Quad-Core Processor

    Note: i didn’t pick best or worst version i picked latest

    with best times i get it bellow 2.8 minute.

    As more notes to the subject:
    xmlrpc-c is no longer dep for cmake so you can scratch that.

  4. With so many pieces of software switching to the two-clause BSD licence and C++, one may as well switch to OpenBSD and KDE (for the respective reasons) :-/

    For clarity: Will CMake be optional for building poppler?

  5. It is not about build time! it is about usability.

    autotools have great advantage to be mature and stable product, results in working at almost any environment using standard system tools.

    While cmake is terrible, look at its opened bug list to figure how much is missing. Look at the syntax and understand how people at the 20th century do not learn from previous experience and reinvent the wheel. Instead of proper scripting (perl, javascript, python) use proprietary primitive syntax.

    And we are not talking about cross compile yet, and none gnu or MS toolchains….

  6. Well, I know and I always say that cmake has issue, but I try to be unbiased the tool improves.

    Surely I’d rather like to have all the software I use and maintain not use cmake, but if there is something good in cmake then it’s better to tell and hope/make sure autotools catch up.

  7. Hello,

    I am trying to use Poppler in my project (that uses CMake).

    I am wondering on how to ‘detect’ poppler from my CMake. Something like FindPoppler() or Find_Package(Poppler) should be of great help – but could not find any.

    Help is appreciated.

    Gopalakrishna Palem

Leave a Reply

Your email address will not be published. Required fields are marked *