Ninja support on Windows #17445
Ninja support on Windows #17445
Conversation
| PGOMGR="${PGOMGR}" | ||
| PHP_BUILD=${PHP_BUILD} | ||
|
|
||
| msvc_deps_prefix = Hinweis: Einlesen der Datei: |
There was a problem hiding this comment.
For an English VS, just remove that line. For other languages, see https://ninja-build.org/manual.html#_deps.
|
I don't really have an opinion on this, I barely care about Windows support. |
We depend on the output (i.e. .rc), and only rc needs that.
This is not properly supported anyway, and gets in the way.
Unfortunately, that requires a hard-coded hack regarding OPcache JIT, since Ninja does not support multiple build lines to specify dependencies. And generally, this increases maintenance burden. Should think about dropping at least some of these fragments in favor of more targeted autoconf macros.
We add implicit output dependencies on .lib to .dll. While we're at it, we also drop a left-over debug output.
Same as with extensions, in build lines we need to split dependencies for technical reasons, but only know all global dependencies at the end of configure.
We also switch to /Z7 to avoid some build flakyness.
|
Regarding the functionality, this is now close to what I had in mind: to be able to do full snapshot builds ( I've already mentioned the performance improvements for debug builds above, and that can also been seen in CI (https://github.com/php/php-src/actions/runs/12734135483/job/35491329533 vs https://github.com/php/php-src/actions/runs/12734364142/job/35491832165). However, Ninja can also be used for clang builds which are in serious need for speed (a minimal release build takes ~5min here with NMake; less than 1.5min with Ninja). |
|
Having had to build on Windows occasionally, I agree that nmake is not great. Ninja seems much better, but I have no experience with it except indirectly when building projects that use it. Switching to CMake would bring Ninja support, but we are far from this, so switching directly to Ninja on Windows seems reasonable, especially since we don't have to re-write or duplicate all the config.w32 files. Maybe we can eventually remove nmake support, so that we can remove the Makefile.frag.w32 files. |
I have doubts that it's worth the effort. So far, I have not spent any time on phpize builds (these are usually pretty fast anyway), and if you want debugging or other tooling (ASan), you're better of doing in-tree (or "pecl-tree") builds. And there are some many more cases that would need to be ported to Ninja, e.g. My main interest is in having a speed-up for actual debug builds and development in general, hopefully with minimally invasive changes to the build chain, and retaining full compatibility with NMake (currently, after
Unfortunately! I would highly appreciate a unified build system, and even thought about switching to autotools on Windows, what is likely possible, but would be painfully slow (even |
|
I don't build that often on Windows and usually doing the minimal builds which is not that slow but if it makes things quicker and better for you, then it makes sense. I don't know much about ninja except using it on some occassions so don't have that much input about it either. Might be worth to hear from @petk as he is progressing with his CMake PHP build by the look of it so he might have some valuable input here as well. |
|
I've filed petk/php-build-system#32. Let's see where that goes. :) |
Contrary to many other make implementations, NMake does not support parallel builds. Instead, MS enabled cl.exe for parallel compilation (
/MP), but that is not allowed for debug builds, likely due to the documented limitation:This implies that debug builds are particularly slow (on my machine, unoptimized debug builds are only minimally faster than fully optimized release builds; they are likely slower on more powerful machines).
Now Visual Studio ships Ninja as part of its CMake support, and Ninja supports parallel builds. Thus I've hacked support for generating a build.ninja into our Windows build tooling; just enough to be able to do a minimal build (
configure --disable-all --enable-cli --enable-debug), and was pleasantly surprised that this improved build time by a factor of three (again, I expect even more impressive results with a more powerful machine). Release builds are also slightly faster (about 10% percent).Since Ninja supports header dependencies almost fully automatically, I've added support for that as well, so it's no longer necessary to take care of that yourself (i.e. when making a change to a header,
nmakewould do nothing; you need to touch relevant files, and for changes to a Zend header, you usually need tonmake clean && nmake– terrible UX). This works currently for German VS installations only (see comment below).Another benefit of using Ninja instead of NMake is the console output during building. While our NMake output is pretty verbose for debug builds, Ninja is terse, usually only showing one line of progress, and only in case of a build failure showing the whole command that failed.
To round this up, there is still of lot of work to be done, but before doing that, I would like to gauge interest in Ninja support – and maybe there are already other alternatives readily available.
Maybe @nielsdos, @arnaud-lb and @bukka are interested in this.
TODO:
--enable-ninjaconfigure flag