Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36209
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain macvicar.net from 72.232.140.210 cause and error)
Message-ID: <E8E768B1-DE06-49E1-8706-3E1AB22B80A6@macvicar.net>
To: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Thu, 20 Mar 2008 00:57:57 +0000
Subject: CMake SoC Proposal
From: scott@macvicar.net (Scott MacVicar)

Hi All,

One of the proposals for Google Summer of Code is a replacement of the =20=

autoconf part of our current build system. This email is a =20
clarification of some of the concerns that may arise if it is accepted =20=

as a project.

The current autoconf system is written using the macro processing =20
language known as m4, this itself causes untold problems for both new =20=

and old developers alike and is a significant barrier to entry for =20
anyone either wanting to build an extension or make a change to the =20
build system.

There would also be support for several compilers, using Mingw or =20
Intel=92s compiler could become a reality. There are probably some =20
slight code tweaks required to achieve this but a user will be able to =20=

chose their compiler.

Furthermore, autoconf is only used for our Unix based systems, for =20
Windows we=92re currently using some cscript files. These don=92t =
provide =20
nearly as much functionality and configuration choices as their =20
autoconf counterparts with a large amount of the Windows build scripts =20=

simply being hardcoded.

---

Here is a quick run down of some of the features of CMake and tools =20
associated with it:

=95 A single configure script that would be used regardless of the OS
=95 A much simpler scripting language
=95 Generates native build files (make, XCode, Visual Studio 6, 7.1, 8)
=95 Use a build directory so that all build related files are outside =20=

the main source tree, no more pollution of your checkout.
=95 Testing support is included and results from these tests can =20
automatically be submitted to our server.
=95 CDash would integrate with CMake and CTest and aggregate the results =
=20
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=3Dcmake
=95 CPack could be used as a new package system as it uses the same =20
scripting language as CMake to abstract packaging. These aren=92t just =20=

tarball but also Windows and OS X installer packages.
=95 Autoconf can live in harmony with CMake even after a transition, =20
we=92re not talking about replacing it outright immediately.


Several large projects have already successfully made either partial =20
or complete transition to CMake:

=95 KDE 4.0
=95 MySQL on Windows
=95 libgd 2.1+

Bill Hoffman of Kitware who produce CMake and the related tools have =20
offered their assistance in our transition, including adding ports to =20=

any unsupported operating systems or features that would prevent us =20
from currently doing the move.

---

For those concerned about the lack of CMake support on your operating =20=

system of choice you=92ll find that most recent Linux distributions =20
provide a copy of CMake and if not then Kitware provide the binaries =20
themselves. These can be installed by non-root users without any issue.

Another alternative would be to simply bundle CMake with PHP, it=92s =20
currently under a BSD license so the only problem here would be the =20
extra space taken up in the package.

Debian, Fedora and FreeBSD all have recent versions of CMake =20
available. For Windows and OS X binaries are provided on the CMake site.

Thanks,
Scott & Pierre-Joye=