Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any plan to add this to php-src? #32

Open
cmb69 opened this issue Jan 17, 2025 · 2 comments
Open

Any plan to add this to php-src? #32

cmb69 opened this issue Jan 17, 2025 · 2 comments

Comments

@cmb69
Copy link

cmb69 commented Jan 17, 2025

This already appears to be a very comprehensive CMake support for building PHP. Kudos!

Do you have any plan to add this to php-src? I would welcome that, because I think CMake (although not perfect) would be a huge improvement over PHP's dual autotools for POSIX and self-made autotools emulation for Windows build chains.

I'm particularly asking, because I have a PR regarding Ninja support for Windows (huge DX improvement) where this repository has been mentioned, and it wouldn't make sense to pursue this if there was direct CMake support for php-src.

Probably also somewhat relevant is php/php-src#16830, which is about pkg-config support on Windows. If there is CMake support in php-src, this likely only makes partial sense, i.e. for packages which are looked up via FindPkgConfig, but not for packages looked up by other means.

@petk
Copy link
Owner

petk commented Jan 18, 2025

Hello, thanks for asking and bringing this up. There is kind of a goal to add this also to php-src at some point. While I understand that php-src is its own repository and teams behind it with established routines. The last time I've discussed this on Slack, there was some "resistance" to this idea though :D which I understand. Changes are always difficult for people used to some way of doing things. And changing or adding more build systems brings lots of workflow changes and required energy to get used to.

Yes, I know, C build systems can be horrible to maintain, understand or migrate. :D And CMake can be also inconvenient with its caveats and weaknesses. It's like that meme where you think you've reached the top of the mountain and suddenly another 10x more difficult path shows up to the finish line :D Or why can't we just have one single CMake file and make everything simple. Or you discover something that completely turns you off with CMake after a year of working with it. But I still believe, it is a bit less horrible than some others. Or the current PHP build system. Every time I've tried doing something in some other build system, it seemed to me that it was more complicated than CMake. Maybe it was only me at that point and perhaps other build systems could be rechecked at some point also.

There are still many unresolved issues in this repository though. Some solutions are at the moment in local branches and in testing phase. For example, installation, cache variables, exporting installation configurations, targets & components naming conventions, finding proper way to build PHP extensions with CMake, and mostly some missing syncs with upstream php-src. This repository is at the moment synced somewhere up to ~90% with upstream Autotools build system, while ~50% with upstream Windows build system to get a better overview.

So, it's difficult to say something firm here at this point. Or how to start with the integration etc.

Windows is also definitely on my list in the very near future to work on it and add missing parts.

Regarding the mentioned changes:

  • The Ninja PR: Sounds good to me if that helps maintaining Windows builds in some way. Yes, Ninja build is very neat overall.
  • The pkg-config PR: I should check it out in more details. On the first glance it seems a bit non-standard and probably could be fine tuned further. The pkg-config on Windows is very difficult to do properly. From what I understand, these are related to dependencies only so the php can find them on Windows. Yes, that kind of seems ok, that they are done somehow like this. But I should really check this out in more details to not give some wrong feedback here.

Well, it's certain that I "idle" here a bit and I'm not moving it forward yet so quickly. However, it is intentionally a bit because I think that it should be worked out to some level where I'm confident enough that it works ok. Something like this. :)

@cmb69
Copy link
Author

cmb69 commented Jan 20, 2025

Well, it's certain that I "idle" here a bit and I'm not moving it forward yet so quickly. However, it is intentionally a bit because I think that it should be worked out to some level where I'm confident enough that it works ok. Something like this. :)

Fair enough!

Or you discover something that completely turns you off with CMake after a year of working with it. But I still believe, it is a bit less horrible than some others. Or the current PHP build system.

That! I'm particularly concerned about the dual POSIX/Windows build chains, which are somewhat similar, but actually completely different (I assume that few users know that the Windows build chain is based on JScript). This is a burden in the long run (you have to maintain two similar, but different build chains), and it may break anytime (MS already deprecated VBScript).

  • The Ninja PR: Sounds good to me if that helps maintaining Windows builds in some way. Yes, Ninja build is very neat overall.

Yes. :)

  • The pkg-config PR: I should check it out in more details. On the first glance it seems a bit non-standard […]

Yeah. As is, it doesn't make much sense; while it would work for winlibs builds, it certainly won't work for vcpkgs etc. which use more standard pkg-config files. I think I should postpone this until winlibs ships "real" pc files.

PS: completely forgot to mention the Windows "hybrids" (for lack of a better term) like MinGW and Cygwin. As is, you can likely build most of PHP with the latter when using the autotools build chain, although there are likely issues (e.g. OPcache preloading would be supported, although that unlikely works due to heavy ASLR on Windows). I don't know if MinGW builds using autotools would work, but the Windows toolchain definitely does not. And this is just because of the strict distinction between Windows toolchain and autotools, which appears to no longer make sense nowadays.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants