Hello internals,
I'm writing to you to find out what the reception here is regarding the
idea of moving the PHP project to build using CMake.
I have looked around and I found 2 attempts of doing just that in the
past (in 2008 via GSoC and something else maybe in 2014 that I couldn't
find the exact info for before writing this email), but nothing came of
those attempts. I have also briefly suggested the idea to Sara Golemon
on Reddit and she didn't seem to be completely against the idea.
For my attempt, I would also optionally use Conan as a means of fetching
dependencies in a cross-platform manner, which would make the need for
OS specific SDKs (like the Windows one) unnecessary. Thanks to CMake's
amazing customizability, using Conan can be made completely optional and
PHP could still continue to build with just system dependencies.
Moving the build system to use CMake instead of the current split
between a *nix and Windows solution would bring everything to one place
and providing CMake bits in the install interface of PHP would make it
easier to develop and use PHP from a development point of view thanks to
CMake packages.
I am planning to make a YouTube video of the whole process of me doing
this grunt work, while I explore the current situation regarding
building PHP and explain what I do and why. I think that it'd generally
be a good thing to have such a video for transparency and it could be
interesting educational material for people who are in a similar
situation and wish to move to building their projects using CMake.
For reference, I occasionally contribute to the CMake project, I'm the
author of https://github.com/friendlyanon/cmake-init which aims to
simplify quickly scaffolding a CMake project that's setup correctly and
I'm in the process of peer reviewing a CMake related book.
Let me know what you think.
Regards,
Horváth V.
Hi Horváth,
just wanted to give my +1 on this one. For our use-case (PHP Embed, ZTS,
Static Build) this would greatly simplify our build-system which is already
using CMake in a lot of parts. Unfortunately I am not a CMake expert, but
could offer help in testing and feedback.
Regards,
Michael
Am Do., 16. Dez. 2021 um 18:53 Uhr schrieb Horváth V. <
friendlyanon_@hotmail.com>:
Hello internals,
I'm writing to you to find out what the reception here is regarding the
idea of moving the PHP project to build using CMake.I have looked around and I found 2 attempts of doing just that in the
past (in 2008 via GSoC and something else maybe in 2014 that I couldn't
find the exact info for before writing this email), but nothing came of
those attempts. I have also briefly suggested the idea to Sara Golemon
on Reddit and she didn't seem to be completely against the idea.For my attempt, I would also optionally use Conan as a means of fetching
dependencies in a cross-platform manner, which would make the need for
OS specific SDKs (like the Windows one) unnecessary. Thanks to CMake's
amazing customizability, using Conan can be made completely optional and
PHP could still continue to build with just system dependencies.Moving the build system to use CMake instead of the current split
between a *nix and Windows solution would bring everything to one place
and providing CMake bits in the install interface of PHP would make it
easier to develop and use PHP from a development point of view thanks to
CMake packages.I am planning to make a YouTube video of the whole process of me doing
this grunt work, while I explore the current situation regarding
building PHP and explain what I do and why. I think that it'd generally
be a good thing to have such a video for transparency and it could be
interesting educational material for people who are in a similar
situation and wish to move to building their projects using CMake.For reference, I occasionally contribute to the CMake project, I'm the
author of https://github.com/friendlyanon/cmake-init which aims to
simplify quickly scaffolding a CMake project that's setup correctly and
I'm in the process of peer reviewing a CMake related book.Let me know what you think.
Regards,
Horváth V.--
To unsubscribe, visit: https://www.php.net/unsub.php
On Thu, Dec 16, 2021 at 6:54 PM Horváth V. friendlyanon_@hotmail.com
wrote:
Hello internals,
I'm writing to you to find out what the reception here is regarding the
idea of moving the PHP project to build using CMake.I have looked around and I found 2 attempts of doing just that in the
past (in 2008 via GSoC and something else maybe in 2014 that I couldn't
find the exact info for before writing this email), but nothing came of
those attempts. I have also briefly suggested the idea to Sara Golemon
on Reddit and she didn't seem to be completely against the idea.For my attempt, I would also optionally use Conan as a means of fetching
dependencies in a cross-platform manner, which would make the need for
OS specific SDKs (like the Windows one) unnecessary. Thanks to CMake's
amazing customizability, using Conan can be made completely optional and
PHP could still continue to build with just system dependencies.Moving the build system to use CMake instead of the current split
between a *nix and Windows solution would bring everything to one place
and providing CMake bits in the install interface of PHP would make it
easier to develop and use PHP from a development point of view thanks to
CMake packages.I am planning to make a YouTube video of the whole process of me doing
this grunt work, while I explore the current situation regarding
building PHP and explain what I do and why. I think that it'd generally
be a good thing to have such a video for transparency and it could be
interesting educational material for people who are in a similar
situation and wish to move to building their projects using CMake.For reference, I occasionally contribute to the CMake project, I'm the
author of https://github.com/friendlyanon/cmake-init which aims to
simplify quickly scaffolding a CMake project that's setup correctly and
I'm in the process of peer reviewing a CMake related book.Let me know what you think.
My main question would be how this will affect 3rd party extensions, which
are currently using autoconf. Will they need to migrate to cmake, or will
we have to effectively maintain both build systems?
Generally, I do think that migrating to cmake makes sense though.
Regards,
Nikita
My main question would be how this will affect 3rd party extensions,
which are currently using autoconf. Will they need to migrate to
cmake, or will we have to effectively maintain both build systems?
Unless 3rd party extensions vendor php-src and/or do something extra
besides what they are instructed to do in the docs (phpize and all the
fun stuff), you can perfectly retain the external functionality for
existing consumers of php-src with the right amount of build system
engineering, which is what I'm offering here.
You could choose this to be maintained for as long as necessary with a
clear migration guide documenting what needs to change, which shouldn't
be a lengthy document if we assume the happy path mentioned above. I am
always available to dispense help for 3rd parties regarding CMake if
necessary.
Regarding that last bit, would it make sense to create a new mailing
list (php.cmake?) where questions could be posted, answered and nicely
organized?
My main question would be how this will affect 3rd party extensions,
which are currently using autoconf. Will they need to migrate to
cmake, or will we have to effectively maintain both build systems?Unless 3rd party extensions vendor php-src and/or do something extra
besides what they are instructed to do in the docs (phpize and all the
fun stuff), you can perfectly retain the external functionality for
existing consumers of php-src with the right amount of build system
engineering, which is what I'm offering here.You could choose this to be maintained for as long as necessary with a
clear migration guide documenting what needs to change, which shouldn't
be a lengthy document if we assume the happy path mentioned above. I am
always available to dispense help for 3rd parties regarding CMake if
necessary.
I don't know anything about Conan. Porting the Zend Engine itself to
use CMake is easy. Bundled extensions are harder, and 3rd party
extensions harder still. I am happy to collaborate on trying this, as
the system we use today is not well understood and I'm shocked it
works as well as it does.
The reason my previous attempt failed (maybe this was the 2014 attempt
you refer to, I don't know), is that I didn't know cmake packages well
enough to handle the extension requirements. I know more about this
today, and with a collaborator to help sustain the momentum on the
project, I feel more confident we could succeed.
As for Nikita's question of "Will they need to migrate to cmake, or
will we have to effectively maintain both build systems?" I think the
answer should be that eventually they should have to migrate, but in
the interim we must maintain two build systems. This is not a great
situation, but I don't see a better way to do this in an open-ended
ecosystem like PHP's.
Again, I am happy to collaborate. Modern CMake is much better than the
phpize system used today.
I think the answer should be that eventually they should have to
migrate, but in the interim we must maintain two build systems.
You are right on the first point, but it is not a requirement for
php-src to be managed by anything other than CMake to maintain phpize
functionality for existing 3rd party software making use of it. From a
quick look, I can tell that it just copies some files that can be
generated/configured by CMake if necessary.
Just so we are in the clear, I'm purposefully abstaining from a deep
dive into php-src's build tooling, because I would really like the video
that I have in mind to be genuine. I had the idea of making a video
about this thanks to Andreas Kling's SerenityOS videos and he follows a
similar process.
I think the answer should be that eventually they should have to
migrate, but in the interim we must maintain two build systems.You are right on the first point, but it is not a requirement for
php-src to be managed by anything other than CMake to maintain phpize
functionality for existing 3rd party software making use of it. From a
quick look, I can tell that it just copies some files that can be
generated/configured by CMake if necessary.
It seems to me the point is the autoconf (emulated on Windows) stuff we
have in php-src which is used by third party extensions in their
config.m4 and config.w32 files. We cannot break that without giving
sufficient time to the respective maintainers to update these extensions
to use the new CMake build system. If we can maintain both build chains
for some years, I'm all for switching to CMake, especially because
building on Windows is a major issue for many extension maintainers,
since the build chain is mostly undocumented, and is missing a lot of
features, like requiring a certain minimum version of a library, or
certain features of it.
Wrt. requiring some package manager, such as Conan: I think we should
try to keep the build requirements at a minimum.
Regarding the discussion platform for a potential CMake migration, maybe
a Github project could be helpful.
Regards,
Christoph
We cannot break that without giving sufficient time to the respective
maintainers to update these extensions to use the new CMake build
system. If we can maintain both build chains for some years
Yes, gradually phasing the current build system out is the most
pragmatic choice, although it will incur some extra maintenance cost for
the time it's still in use, but it's better to do something sooner than
later. This will also allow php-src to drop the Windows SDK altogether
that was recently moved to the GH org, because Microsoft stopped
maintenance.
Wrt. requiring some package manager, such as Conan: I think we
should try to keep the build requirements at a minimum.
I have absolutely no intention of dependency manager lock-in. Conan
allows transparent integration with CMake and it also makes grabbing
things like bison trivial on Windows. For Linux users, they can happily
continue to use their system dependency manager or opt into using
Conan, but the choice is left up to the one building the project, not
the project itself.
I have this example repository I have created to show transparent Conan
usage with a CMake project:
https://github.com/friendlyanon/cmake-init-conan-example
The only way the project ever interacts with Conan is if the preset used
to configure inherits from the "conan" preset, otherwise CMake will not
be provided with additional prefixes to search from Conan.
Please note that this repository was made before I was made aware that
using their utility script "conan.cmake" isn't really the best way to
use Conan in CMake projects and it's really intended as stopgap
solution. I will look into profiles and make use of Conan properly
eventually, which means I will use the above project as a playground to
test things first.
Regarding the discussion platform for a potential CMake migration,
maybe a Github project could be helpful.
Either way works for me as long as people with questions can reach me or
other interested parties regarding CMake. I guess GH has the added
advantage of better discoverability than mailing lists.
Hi
Den fre. 17. dec. 2021 kl. 01.09 skrev Horváth V. friendlyanon_@hotmail.com:
Yes, gradually phasing the current build system out is the most
pragmatic choice, although it will incur some extra maintenance cost for
the time it's still in use, but it's better to do something sooner than
later. This will also allow php-src to drop the Windows SDK altogether
that was recently moved to the GH org, because Microsoft stopped
maintenance.
I feel it is important to clarify something here. The Windows SDK is
still supported by Microsoft. The Binary SDK for PHP by Microsoft
which is the SDK that manages dependencies and provides cross MSVC
environment build scripts is no longer supported.
You can still build PHP on Windows without the Binary SDK but you will
have to manage the build depedencies in all their flavors manually
without this Binary SDK for PHP.
Kalle Sommer Nielsen
kalle@php.net
Hi
Den fre. 17. dec. 2021 kl. 01.09 skrev Horváth V. <
friendlyanon_@hotmail.com>:Yes, gradually phasing the current build system out is the most
pragmatic choice, although it will incur some extra maintenance cost for
the time it's still in use, but it's better to do something sooner than
later. This will also allow php-src to drop the Windows SDK altogether
that was recently moved to the GH org, because Microsoft stopped
maintenance.I feel it is important to clarify something here. The Windows SDK is
still supported by Microsoft. The Binary SDK for PHP by Microsoft
which is the SDK that manages dependencies and provides cross MSVC
environment build scripts is no longer supported.You can still build PHP on Windows without the Binary SDK but you will
have to manage the build depedencies in all their flavors manually
without this Binary SDK for PHP.
We may switch to vcpkg distributions, which supports cmake out of the box
as well, or the current autoconf php js port works too.
best,
We may switch to vcpkg distributions, [...], or the current autoconf
php js port works too.
Could you elaborate on what you mean by these?
The reason why I prefer Conan here is because they provide pre-built
binaries for common setups, so that makes builds go faster for the
majority of the cases. I'm not against having a vcpkg manifest either
way, since that's just a simple JSON file at the root of the project,
but that will result in duplication and one more thing to maintain.
We may switch to vcpkg distributions, [...], or the current autoconf
php js port works too.Could you elaborate on what you mean by these?
The reason why I prefer Conan here is because they provide pre-built
binaries for common setups, so that makes builds go faster for the
majority of the cases. I'm not against having a vcpkg manifest either
way, since that's just a simple JSON file at the root of the project,
but that will result in duplication and one more thing to maintain.
I assume that Pierre was referring to the Windows dependency libraries.
Anyhow, I suggest to defer the Windows support; it appears to be more
important to have a CMake based build system working for other platforms
first, and then we can still figure out how to make that useable on
Windows, too. In other words, eating the elephpant one bite at a time. :)
Christoph
The point of CMake is that you don't have to care too much about the
system you are building the software on. The exact same CMake build
files will work on all platforms that CMake supports. There is no
"Windows support" specifically when you are working with CMake. In fact,
I work on a Windows machine so I'll be adding CMake build tooling from
that :)
Same goes to Conan and vcpkg AFAICT. But even then, their integration
would be completely optional and transparent, so people can pick and
choose between one of those or system dependencies.
The point of CMake is that you don't have to care too much about the
system you are building the software on. The exact same CMake build
files will work on all platforms that CMake supports. There is no
"Windows support" specifically when you are working with CMake.
Yeah, but you need all build dependencies on Windows, and that is more
difficult than on many other systems. The PHP SDK binary tools ship
several necessary tools, but of course you could get them by other
means. However, the libraries are more of an issue. vcpkg has a lot of
these, but some are completely missing (e.g. libxpm), and some packages
are even on older versions than we currently use for Windows builds.
The prebuilt Windows dependencies[1] mostly lack potentially required
CMake config-file packages. All this can be fixed as appropriate, but I
wouldn't try to address that right away, and I think we want to ship
Windows binaries with the feature set that we currently have.
[1] https://windows.php.net/downloads/php-sdk/deps/
In fact,
I work on a Windows machine so I'll be adding CMake build tooling from
that :)
If that works, all the better. :)
Same goes to Conan and vcpkg AFAICT. But even then, their integration
would be completely optional and transparent, so people can pick and
choose between one of those or system dependencies.
Christoph
vcpkg has a lot of these, but some are completely missing (e.g.
libxpm), and some packages are even on older versions than we
currently use for Windows builds.
Good point, even Conan is missing some of those dependencies. Guess I'll
have to package those dependencies in Conan Center Index first, which is
not a big issue, since I wasn't planning to start working on PHP this
year, just to let everyone think things through.
The prebuilt Windows dependencies[1] mostly lack potentially
required CMake config-file packages.
That's not really an issue. PHP is an application and not a library, so
it can afford to not rely on CMake packages to find dependencies. In
libraries you are usually restricted to find_package() to make things
work properly transitively. Conan can in fact generate CMake packages
for libraries that don't support clients using CMake, but that would
lead to lock-in if PHP were to use those and my aim is to make things
work regardless what method is used to fetch dependencies.
We may switch to vcpkg distributions, [...], or the current autoconf
php js port works too.Could you elaborate on what you mean by these?
The reason why I prefer Conan here is because they provide pre-built
binaries for common setups, so that makes builds go faster for the
majority of the cases. I'm not against having a vcpkg manifest either
way, since that's just a simple JSON file at the root of the project,
but that will result in duplication and one more thing to maintain.I assume that Pierre was referring to the Windows dependency libraries.
Anyhow, I suggest to defer the Windows support; it appears to be more
important to have a CMake based build system working for other platforms
first, and then we can still figure out how to make that useable on
Windows, too. In other words, eating the elephpant one bite at a time. :)
actually better to do it together or closely.
Cross compilation works, or miltiplarform too. But doing it late is a pain.
Also, I did not check which platforms are currently supported by cmake but
it was the main reason back then to stick to autotools.
And btw, vcpkg is only about dropping our own builds for all libraries
needed. :)
best,
Pierre
We may switch to vcpkg distributions, [...], or the current autoconf
php js port works too.Could you elaborate on what you mean by these?
The reason why I prefer Conan here is because they provide pre-built
binaries for common setups, so that makes builds go faster for the
majority of the cases. I'm not against having a vcpkg manifest either
way, since that's just a simple JSON file at the root of the project,
but that will result in duplication and one more thing to maintain.
I meant the current autoconf port (using js) on windows works perfectly
with vcpkg.
best,
My main question would be how this will affect 3rd party extensions,
which are currently using autoconf. Will they need to migrate to
cmake, or will we have to effectively maintain both build systems?
We would have to keep our autoconf macros for phpize aroudn for a
while. Interoperability for out-of-tree-builds shouldn't be a problem
as long as a php-config script/tool is generated.
For building in PHP's tree (as static extension) the external vendors
would have to provide CMake files.
For building out of tree with CMake we should be able to produce the
FindPHP CMake macros.
Also the "pecl" tool (or a replacement) would need adaption.
But yes, we will need a bit of a grace period for everybody to adapt.
While I assume most will be happy to make the switch.
johannes
One thing I forgot to ask is what minimum CMake version should php-src
support in its build scripts? For reference, please take a look at
repology.org for the packaging status of CMake across a lot of software
distributions: https://repology.org/project/cmake/badges
Please note that the lower you go, the less convenience you will be
afforded and the more workarounds you will have to implement to have
that convenience.
Personally, I posit that targeting 3.8 would still allow vast majority
of people to depend on nothing but their system package manager, however
I must note that upgrading CMake is trivial and I recommend anyone
wanting to verify that to read Alex Reinking's blog post about this:
https://alexreinking.com/blog/how-to-use-cmake-without-the-agonizing-pain-part-1.html
One thing I forgot to ask is what minimum CMake version should php-src
support in its build scripts? For reference, please take a look at
repology.org for the packaging status of CMake across a lot of software
distributions: https://repology.org/project/cmake/badges
This is way too early to decide this. This is a decision to be made
when we're actually ready to try publishing it for regular consumption
(not for the people developing it).
For the sake of just sticking a number in that place in the cmake file
for now, I recommend 3.16 as this is what is in Ubuntu 20.04. It may
take us a few months to develop the cmake system, or it may take
years, but hopefully not so many years that Ubuntu 20.04 becomes
irrelevant. Better to downgrade in the end if necessary.
This is way too early to decide this. This is a decision to be made
when we're actually ready to try publishing it for regular
consumption (not for the people developing it).
Sure. I wasn't expecting concrete answers, just letting people know that
this ought to be considered as well.
It may take us a few months to develop the cmake system, or it may
take years, but hopefully not so many years that Ubuntu 20.04
becomes irrelevant.
That feels like a bit of an exaggeration to me. With nothing else taking
my time up, I'm confident I can do the initial work in a week or two.
Unless you mean the total transition, dropping the existing solution and
all that.
I'm writing to you to find out what the reception here is regarding the
idea of moving the PHP project to build using CMake.
I think this would be a great move overall.
Would the CMake build chain be backported? I'm assuming not, which means
extensions who support older PHP versions than the one that introduces
CMake will need to support autoconf for as long as they want to support
those older PHP versions, I think?
That isn't a deal breaker for me, but a guide on adding support for CMake
would definitely be appreciated and helpful for extension maintainers IMO.
But yes, overall great idea!
Thanks
James
Hey internals,
Just a quick update on this in between the holidays.
There are indeed quite a few of the libraries provided in the php-src's
Windows SDK that are missing from Conan Center Index, which is the
default remote when fetching dependencies using Conan.
I have submitted a recipe for WinEditLine and it is pending review by
the Conan team. I am basically done with OpenLDAP's recipe as well, but
it needs Cyrus SASL as a dependency, which does not build on Windows
using the CCI recipe yet.
Ironically, many of PHP's dependencies use Autotools as their build
tool, which makes it practically impossible to build them cross
platform, so I have to rewrite things in terms of CMake :)
Regards,
Horváth V.
Just a quick update on this in between the holidays.
There are indeed quite a few of the libraries provided in the php-src's
Windows SDK that are missing from Conan Center Index, which is the
default remote when fetching dependencies using Conan.I have submitted a recipe for WinEditLine and it is pending review by
the Conan team. I am basically done with OpenLDAP's recipe as well, but
it needs Cyrus SASL as a dependency, which does not build on Windows
using the CCI recipe yet.Ironically, many of PHP's dependencies use Autotools as their build
tool, which makes it practically impossible to build them cross
platform, so I have to rewrite things in terms of CMake :)
Right! This is why I suggested to postpone Windows support for now. :)
The core dependencies for Windows builds are currently hosted at
https://github.com/winlibs; some can be built using
https://github.com/winlibs/winlib-builder. Of course, it would
preferable to be able to build all the libs with CMake, instead of the
current mix of self made or provided Makefiles, Visual Studio solutions,
and what not.
Christoph
This is why I suggested to postpone Windows support for now.
This would have to be done either way and I prefer to work from the host
OS on my computer, especially since the Windows side of things is what's
messy right now and I don't like things being unnecessarily messy for no
good reason.
Once I have things packaged via Conan as well, I will have a better idea
of how to adapt the existing ways of people consuming dependencies. Here
I'm thinking about the name of libraries that should be used in CMake if
there is no proper CMake package found.
As an example, the Conan package of WinEditLine provides an edit.lib
file when built as a static library, which follows the idiomatic way of
naming this file on Windows, however the php-sdk provided binary is
called edit_a.lib, which tries to mimic the UNIX way of naming things.
In the above case I would have to first do a find_package(wineditline
NO_MODULE) to try finding the Conan generated config files and after
that I would need to use the other find_*() commands with all known
names in use as search parameters, then decide whether it's actually a
static or a shared library. Things get painful once you don't have the
convenience of CMake configs encoding crucial details about your
dependencies.
This is why I suggested to postpone Windows support for now.
This would have to be done either way and I prefer to work from the host
OS on my computer, especially since the Windows side of things is what's
messy right now and I don't like things being unnecessarily messy for no
good reason.Once I have things packaged via Conan as well, I will have a better idea
of how to adapt the existing ways of people consuming dependencies. Here
I'm thinking about the name of libraries that should be used in CMake if
there is no proper CMake package found.As an example, the Conan package of WinEditLine provides an edit.lib
file when built as a static library, which follows the idiomatic way of
naming this file on Windows, however the php-sdk provided binary is
called edit_a.lib, which tries to mimic the UNIX way of naming things.
In the above case I would have to first do a find_package(wineditline
NO_MODULE) to try finding the Conan generated config files and after
that I would need to use the other find_*() commands with all known
names in use as search parameters, then decide whether it's actually a
static or a shared library. Things get painful once you don't have the
convenience of CMake configs encoding crucial details about your
dependencies.
Ah, right! The naming scheme of libraries used to build PHP and PECL
packages is uncommon, but in use for a long time, and it's even
documented[1]. I'm not sure if we can change it for a minor PHP
version. And simply renaming the libraries won't work, since that
breaks the "link" to the .pdb files.
Not sure how to solve this. :(
[1]
https://wiki.php.net/internals/windows/libs#general_compiling_guidelines
Christoph
Just a quick update on this in between the holidays.
There are indeed quite a few of the libraries provided in the php-src's
Windows SDK that are missing from Conan Center Index, which is the
default remote when fetching dependencies using Conan.I have submitted a recipe for WinEditLine and it is pending review by
the Conan team. I am basically done with OpenLDAP's recipe as well, but
it needs Cyrus SASL as a dependency, which does not build on Windows
using the CCI recipe yet.Ironically, many of PHP's dependencies use Autotools as their build
tool, which makes it practically impossible to build them cross
platform, so I have to rewrite things in terms of CMake :)Right! This is why I suggested to postpone Windows support for now. :)
The core dependencies for Windows builds are currently hosted at
https://github.com/winlibs; some can be built using
https://github.com/winlibs/winlib-builder. Of course, it would
preferable to be able to build all the libs with CMake, instead of the
current mix of self made or provided Makefiles, Visual Studio solutions,
and what not.
I would rather separate external libs challenges from the php cmake move.
CMake macros allow all kind of detection anyway, pkgconfig or custom.
Conan looks good while I never tried it. There are other, *nix only, or
win and unix, ie vcpkg which has all php deps afair.
Also cmake is for php, I would prefer to move away from our custom builds
scripts for external libs on windows, very hard to maintain and not
scalable.
best,
Like I said in another e-mail, I wish to work on my host OS and this is
something that would need to be done either way. It won't take me long
either and PHP has been chugging along nicely so far without CMake.
vcpkg has more dependencies missing than Conan and Conan has the
advantage of providing pre-built binaries. For vcpkg, Open LDAP is
missing, Cyrus SASL is missing, Bison is missing, Flex is missing, etc.
After New Year's, I will get to grinding out the dependencies that are
missing in Conan and depending on how fast my PRs are accepted to CCI, I
may be able to start working on PHP itself in February. Most of the time
will be taken up by adjusting documentation, PHP provided tooling for
extensions and gathering feedback from existing extension developers, so
there is no reason to hurry.
I think I will create a summary issue on the Conan Center Index
repository with checkboxes to track my progress. Please look forward to
that and consider subscribing to that issue if you are interested.
Regards,
Horváth V.
good evening Horváth,
Like I said in another e-mail, I wish to work on my host OS and this is
something that would need to be done either way. It won't take me long
either and PHP has been chugging along nicely so far without CMake.vcpkg has more dependencies missing than Conan and Conan has the
advantage of providing pre-built binaries. For vcpkg, Open LDAP is
missing, Cyrus SASL is missing, Bison is missing, Flex is missing, etc.
excellent, Conan it is then :)
After New Year's, I will get to grinding out the dependencies that are
missing in Conan and depending on how fast my PRs are accepted to CCI, I
may be able to start working on PHP itself in February. Most of the time
will be taken up by adjusting documentation, PHP provided tooling for
extensions and gathering feedback from existing extension developers, so
there is no reason to hurry.I think I will create a summary issue on the Conan Center Index
repository with checkboxes to track my progress. Please look forward to
that and consider subscribing to that issue if you are interested.
I will definitely follow it and see what can be done in pickle to support
it as well as the legacy build system.
thank you for pushing it forward, much needed :)
best,
Pierre
I have created an issue to track dependencies for PHP:
https://github.com/conan-io/conan-center-index/issues/8618
Please take a look, verify that all of those are needed and if anyone
has answers for the few questions I have as sublist items, then that
would help greatly as well.
Regards,
Horváth V.
I have created an issue to track dependencies for PHP:
https://github.com/conan-io/conan-center-index/issues/8618Please take a look, verify that all of those are needed and if anyone
has answers for the few questions I have as sublist items, then that
would help greatly as well.
glib: yes, that should be shared libraries; at least parts of that
package are used by some PECL extensions
ICU: "Some platforms aren't supported." – which platforms?
libargon2: should probably be available in addition to the libsodium
implementation; might be acceptable if not
libintl: is indeed the supporting library for gettext
libsodium: support for VS < 2019 is unlikely to be needed
And yes, all these are needed (maybe libargon2 not necessarily) for
php-src. There are many more for PECL extensions.
Regards,
Christoph
Thanks for the reply. It's very helpful.
The glib issue is an upstream issue on Windows:
https://gitlab.gnome.org/GNOME/glib/-/issues/692
ICU's Conan recipe doesn't support some platforms:
https://github.com/conan-io/conan-center-index/blob/4011e625faf3c9de7b5a3c37cc736a6545ff9152/recipes/icu/all/conanfile.py#L76-L101
Regards,
Horváth V.
Thanks for the reply. It's very helpful.
The glib issue is an upstream issue on Windows:
https://gitlab.gnome.org/GNOME/glib/-/issues/692
Ah, sorry, that shouldn't be a problem (at least for Windows), since we
need shared libraries there anyway.
ICU's Conan recipe doesn't support some platforms:
https://github.com/conan-io/conan-center-index/blob/4011e625faf3c9de7b5a3c37cc736a6545ff9152/recipes/icu/all/conanfile.py#L76-L101
Oh, that would be an issue. We can't use Cygwin builds; MinGW builds
might be okayish, though. ICU ships a VS solution file
(source/allinone/allinone.sln) which works fine. I don't know whether
using that would be okay for Conan.
Also note that we're using a patched libffi[1]; since that patch is not
complete, I didn't submit it upstream, but at least this basic
__vectorcall support is important for ext/ffi.
[1]
https://github.com/winlibs/libffi/commit/0d0ab67e54893e7f140e4401d56901899586f4ce
Regards,
Christoph
Oh, that would be an issue. We can't use Cygwin builds; MinGW builds
might be okayish, though. ICU ships a VS solution file
(source/allinone/allinone.sln) which works fine. I don't know
whether using that would be okay for Conan.
No need to worry about that, it's just a way to coerce ICU's build
system into behaving well on Windows. Conan uses Msys2 as a build
environment for projects with *nix lock-in, which produces native
binaries without the cygwin shenanigans.
Also note that we're using a patched libffi[1]; since that patch is
not complete, I didn't submit it upstream, but at least this basic
__vectorcall support is important for ext/ffi.
That's a tough one. I see you commented on the issue regarding this:
https://github.com/libffi/libffi/issues/500#issuecomment-671037484
I'm not sure what should be done in this case. I have a feeling the
Conan team would not welcome such a partial feature patch. Maybe having
an Artifactory server on php.net, where a custom recipe is hosted would
solve this. I'm sure if the Conan team was contacted about this, then
they would be glad to help.
Oh, that would be an issue. We can't use Cygwin builds; MinGW builds
might be okayish, though. ICU ships a VS solution file
(source/allinone/allinone.sln) which works fine. I don't know
whether using that would be okay for Conan.No need to worry about that, it's just a way to coerce ICU's build
system into behaving well on Windows. Conan uses Msys2 as a build
environment for projects with *nix lock-in, which produces native
binaries without the cygwin shenanigans.
what does it mean exactly here?
it uses msys for autoconf and co support but actually uses vc? or it relies
on gcc and co?
it uses msys for autoconf and co support but actually uses vc?
Exactly.
Unless you have another compiler specified in your Conan profile. You
can see in the _platform method that the dictionary is indexed with
self.settings.os and self.settings.compiler, both of which come from the
selected profile. Taking that into account, Windows + VS is supported.
The value in the dictionary is just used to massage the existing ICU
build system into emitting files that can be used to build with VS.
Oh, that would be an issue. We can't use Cygwin builds; MinGW builds
might be okayish, though. ICU ships a VS solution file
(source/allinone/allinone.sln) which works fine. I don't know
whether using that would be okay for Conan.No need to worry about that, it's just a way to coerce ICU's build
system into behaving well on Windows. Conan uses Msys2 as a build
environment for projects with *nix lock-in, which produces native
binaries without the cygwin shenanigans.what does it mean exactly here?
it uses msys for autoconf and co support but actually uses vc? or it
relies on gcc and co?
rt*m :)
it can use whatever is needed and prioritization of cmd in the paths is
supported, neat :)
https://docs.conan.io/en/latest/systems_cross_building/windows_subsystems.html