# CMake SoC Proposal - Thread: https://externals.io/message/36209 - Original archive: https://news-web.php.net/php.internals/36209 - Started by Scott MacVicar on 2008-03-20T00:57:57+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #36209 — Scott MacVicar — 2008-03-20T00:57:57+00:00 URL: https://externals.io/message/36209#36209 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 --- ## #36211 — Gwynne Raskind — 2008-03-20T01:23:16+00:00 URL: https://externals.io/message/36209#36211 My two US cents :). > > […] > m4 is simple. :-p Since when? > > […] > 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. > > […] > 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. > > […] > 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." --- ## #36222 — Cristian Rodriguez — 2008-03-20T16:29:58+00:00 URL: https://externals.io/message/36209#36222 · In reply to: #36209 2008/3/19, Scott MacVicar : > Another alternative would be to simply bundle CMake with PHP, Nope, Cmake is available in almost all distributions and in the case some of them dont have it yet, they will because sooner or later will need to integrate KDE4. Please dont bundle more stuff in PHP, life is already painful ( bundled PCRE, regexp, libzip, libgd , timezonedb..) dont add yet another duplicate task for distributors. -- "If debugging is the process of removing bugs, then programming must be the process of putting them in." – Edsger Dijkstra http://www.cristianrodriguez.net --- ## #36224 — Pierre Joye — 2008-03-20T17:59:06+00:00 URL: https://externals.io/message/36209#36224 · In reply to: #36222 On Thu, Mar 20, 2008 at 5:29 PM, Cristian Rodriguez wrote: > 2008/3/19, Scott MacVicar : > > > > […] > > Nope, Cmake is available in almost all distributions and in the case > some of them dont have it yet, they will because sooner or later will > need to integrate KDE4. > > Please dont bundle more stuff in PHP, life is already painful ( > bundled PCRE, regexp, libzip, libgd , timezonedb..) dont add yet > another duplicate task for distributors. As I agree with you, libgd and libzip are two wrong examples, they are not simply bundled, they are different (fork for libgd). Especially libgd as our version is not the same as the official version from a feature and behavior point of view. That will change soon but it is not yet the case. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36530 — Pierre Joye — 2008-03-26T11:12:47+00:00 URL: https://externals.io/message/36209#36530 > Gwynne Raskind wrote: > > […] > > 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 --- ## #36531 — Pierre Joye — 2008-03-26T11:14:53+00:00 URL: https://externals.io/message/36209#36531 · In reply to: #36222 On Thu, Mar 20, 2008 at 5:29 PM, Cristian Rodriguez wrote: > 2008/3/19, Scott MacVicar : > > > > […] > > Nope, Cmake is available in almost all distributions and in the case > some of them dont have it yet, they will because sooner or later will > need to integrate KDE4. > The only place where it would make sense to bundled it is on windows, in our "SDK" (aka zip.zip which should really be moved to a true PHP SDK, php-devel package, one of these days :) ). But as CMake provides binaries for windows (and for almost all platforms), a simple link should suffice. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org