Everything

php

Home » Project » Newsgroups » php.internals » Surveying interest regarding CMake »

Surveying interest regarding CMake

php.internals

Horváth V.

4 years ago

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.

Michael Maroszek

4 years ago

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>:

Nikita Popov

4 years ago

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

Horváth V.

4 years ago

> 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?

Unnamed Person

4 years ago

On Thu, Dec 16, 2021 at 1:13 PM Horváth V. <friendlyanon_@hotmail.com> wrote:

>
> > 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.

Horváth V.

4 years ago

> 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.

Christoph Becker

4 years ago

On 16.12.2021 at 22:31, Horváth V. wrote:

>> 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

Horváth V.

4 years ago

> 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.

Kalle Sommer Nielsen

4 years ago

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

Pierre Joye

4 years ago

On Fri, Dec 17, 2021, 10:23 PM Kalle Sommer Nielsen <kalle@php.net> wrote:

> 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,

Horváth V.

4 years ago

On 2021. 12. 20. 17:19, Pierre Joye wrote:

> 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.

Johannes Schlueter

4 years ago

On Thu, 2021-12-16 at 20:15 +0100, Nikita Popov wrote:

> 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

Horváth V.

4 years ago

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

Unnamed Person

4 years ago

On Fri, Dec 17, 2021 at 6:49 AM Horváth V. <friendlyanon_@hotmail.com> wrote:

>
> 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.

Horváth V.

4 years ago

> 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.

James Titcumb

4 years ago

On Thu, 16 Dec 2021, 17:53 Horváth V., <friendlyanon_@hotmail.com> wrote:

>
> 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

Horváth V.

4 years ago

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.

Christoph Becker

4 years ago

On 29.12.2021 at 13:38, Horváth V. wrote:

> 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

Horváth V.

4 years ago

On 2021. 12. 29. 14:02, Christoph M. Becker wrote:

> 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.

Christoph Becker

4 years ago

On 29.12.2021 at 18:41, Horváth V. wrote:

> On 2021. 12. 29. 14:02, Christoph M. Becker wrote:
>
>> 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

Pierre Joye

4 years ago

On Wed, Dec 29, 2021, 8:02 PM Christoph M. Becker <cmbecker69@gmx.de> wrote:

> On 29.12.2021 at 13:38, Horváth V. wrote:
>
> > 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,

Horváth V.

4 years ago

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.

Pierre Joye

4 years ago

good evening Horváth,

On Thu, Dec 30, 2021, 11:49 PM Horváth V. <friendlyanon_@hotmail.com> wrote:

> 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

Horváth V.

4 years ago

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.

Christoph Becker

4 years ago

On 03.01.2022 at 17:29, Horváth V. wrote:

> 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.

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

Horváth V.

4 years ago

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.

Christoph Becker

4 years ago

On 03.01.2022 at 18:03, Horváth V. wrote:

> 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