CMake SoC Proposal View as Markdown

Hi All,

One of the proposals for Google Summer of Code is a replacement of the
autoconf part of our current build system. This email is a
clarification of some of the concerns that may arise if it is accepted
as a project.

The current autoconf system is written using the macro processing
language known as m4, this itself causes untold problems for both new
and old developers alike and is a significant barrier to entry for
anyone either wanting to build an extension or make a change to the
build system.

There would also be support for several compilers, using Mingw or
Intel’s compiler could become a reality. There are probably some
slight code tweaks required to achieve this but a user will be able to
chose their compiler.

Furthermore, autoconf is only used for our Unix based systems, for
Windows we’re currently using some cscript files. These don’t provide
nearly as much functionality and configuration choices as their
autoconf counterparts with a large amount of the Windows build scripts
simply being hardcoded.

Here is a quick run down of some of the features of CMake and tools
associated with it:

• A single configure script that would be used regardless of the OS
• A much simpler scripting language
• Generates native build files (make, XCode, Visual Studio 6, 7.1, 8)
• Use a build directory so that all build related files are outside
the main source tree, no more pollution of your checkout.
• Testing support is included and results from these tests can
automatically be submitted to our server.
• CDash would integrate with CMake and CTest and aggregate the results
from the tests showing failing tests on the various systems.
CMake's own dashboard can be seen at http://public.kitware.com/dashboard.php?name=cmake
• CPack could be used as a new package system as it uses the same
scripting language as CMake to abstract packaging. These aren’t just
tarball but also Windows and OS X installer packages.
• Autoconf can live in harmony with CMake even after a transition,
we’re not talking about replacing it outright immediately.

Several large projects have already successfully made either partial
or complete transition to CMake:

• KDE 4.0
• MySQL on Windows
• libgd 2.1+

Bill Hoffman of Kitware who produce CMake and the related tools have
offered their assistance in our transition, including adding ports to
any unsupported operating systems or features that would prevent us
from currently doing the move.

For those concerned about the lack of CMake support on your operating
system of choice you’ll find that most recent Linux distributions
provide a copy of CMake and if not then Kitware provide the binaries
themselves. These can be installed by non-root users without any issue.

Another alternative would be to simply bundle CMake with PHP, it’s
currently under a BSD license so the only problem here would be the
extra space taken up in the package.

Debian, Fedora and FreeBSD all have recent versions of CMake
available. For Windows and OS X binaries are provided on the CMake site.

Thanks,
Scott & Pierre-Joye

My two US cents :).

Here is a quick run down of some of the features of CMake and tools
associated with it:
• A single configure script that would be used regardless of the OS
• A much simpler scripting language
m4 is simple. :-p

Since when?

• Generates native build files (make, XCode, Visual Studio 6, 7.1, 8)
err..a simple Makefile isn't "native" enough? Like we have right
now? :)
Care to explain what you meant with this?

Make is outmoded, outdated, and not up to the task of modern builds.
You can't use a Makefile (effectively) with Xcode.

• Use a build directory so that all build related files are outside
the main source tree, no more pollution of your checkout.
You can do that already even with autoconf generated configure: Just
call the configure script from wherever you want to build the stuff.
(I build PHP always outside the source tree to not pollute my
checkout. :)

As do I, but I still have to pollute my checkout with buildconf or
csript buildconf.js.

Bill Hoffman of Kitware who produce CMake and the related tools
have offered their assistance in our transition, including adding
ports to any unsupported operating systems or features that would
prevent us from currently doing the move.
phpize is the one and only thing that comes to my mind as an
obstacle..but it's propably possible to simulate using this CMake
thingie? Everyone has CMake installed, right? :D

If automake and autoconf can do it, then as a rule CMake can do it
better.

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

Gwynne Raskind wrote:

My two US cents :).

Here is a quick run down of some of the features of CMake and tools
associated with it:
• A single configure script that would be used regardless of the OS
• A much simpler scripting language
m4 is simple. :-p

Since when?

m4 is actually one of the simplest languages around. There really isn't
much to it. The pain point of autoconf/automake/libtool isn't m4, it is
the complicated and often obtuse relationship between those 3 tools.

I don't mind exploring cmake, but it is a massive undertaking to create
something that can build PHP on every UNIX and pseudo-UNIX platform out
there. We should figure out what the main goal here is. If it is
simply getting "native" build files so people can use their
pointy-clickety interfaces to build PHP, then it is probably way easier
to create .in files to generate those basic build templates from our
current system than it is to rewrite the whole thing.

To have a pointy-clickety (I like this word :) interface is
definitively not a goal. It is a side effect of using CMake as CMake
has a GUI available on unix and windows. The main goal is actually to
have one single tool for all platforms and to lower the barriers of
the build scripts.

Cheers,

Pierre
http://blog.thepimp.net | http://www.libgd.org