[request] Dependencies of PHP (summary issue)

[friendlyanon]

This is a summary issue tracking progress for dependencies of the php-src runtime of PHP programming language. These are provided on windows.php.net for Windows, but the goal would be to make them build easily on all platforms in a reproducible way.

Not on CCI yet or needs some work

• apache (https://httpd.apache.org/)
• c-client (https://github.com/uw-imap/imap)
  • Add c-client/2007f #8901
  • Needs [request] krb5/1.18.3 #4102 for MacOS
• fbclient (https://www.firebirdsql.org/pdfmanual/html/ufb-cs-clientlib.html)
  • Add fbclient/3.0.8 #9555
  • Issues:
    • [question] Dealing with a project that builds its own build tools #9307
  • Requirements:
    • Add btyacc/3.0 #8947
    • Add asfernandes-cloop/0.0.0 #8951
• glib (https://www.gtk.org/)
  • Can't build as static library on Windows. Is this a problem?
• ICU (https://icu.unicode.org/)
  • Some platforms aren't supported. Is this an issue?
• libargon2 (https://github.com/p-h-c/phc-winner-argon2)
  • There is already libsodium. Is this needed?
• libavif (https://github.com/AOMediaCodec/libavif)
  • Add libavif/0.9.3 #9225
• libenchant2 (https://github.com/AbiWord/enchant)
  • Add enchant/2.3.2 #9695
  • Requirements:
    • Add hunspell/1.7.0 #9203
• libffi (https://sourceware.org/libffi/)
  • Package info needs better CMake support.
  • Needs vectorcall support
    • Partially solved, see Support for __vectorcall calling convention libffi/libffi#500 (comment).
      This likely will not be accepted to CCI. Probably need to setup an Artifactory server on php.net.
• libintl (https://www.gnu.org/software/gettext/gettext.html)
  • Seems to be part of gettext. Is that right?
• liblmdb (https://www.symas.com/lmdb)
  • Package info needs better CMake support.
• libqdbm (http://fallabs.com/qdbm/)
  • Add qdbm/1.8.78 #8676
• libsasl (https://www.cyrusimap.org/sasl/)
  • Doesn't compile on Windows.
• libsodium (https://github.com/jedisct1/libsodium)
  • Can't build with VS <2015 and shared library with static runtime doesn't work. Is this a problem?
• libxpm (https://cgit.freedesktop.org/xorg/lib/libXpm)
  • Add libxpm/3.5.13 #8786
  • Needs [request] xorg/system on MacOS #8790 for MacOS
• libxslt (https://xmlsoft.org)
  • Package info needs better CMake support.
• net-snmp (http://www.net-snmp.org/)
  • Add net-snmp/5.9.1 #8668
• nghttp2 (https://nghttp2.org)
  • Package info needs better CMake support.
• openldap (https://www.openldap.org/)
  • Basically finished locally, just needs Cyrus SASL as a dependency.
• wineditline (http://mingweditline.sourceforge.net)
  • Add wineditline/2.206 #8553

I will keep editing this list as I work through each item. If I got something wrong, then please let me know.

[friendlyanon]

Mailing list post: https://externals.io/message/116655#116779

[pierrejoye]

glib

we do build it shared already for enchant. What is the issue you are experiencing?

libintl

yes, part of gettext

[friendlyanon]

What is the issue you are experiencing?

It's an upstream issue.

conan-center-index/recipes/glib/all/conanfile.py

Lines 52 to 56 in 58a0fe0

	if self.settings.os == "Windows" and not self.options.shared:
	raise ConanInvalidConfiguration(
	"glib can not be built as static library on Windows. "
	"see https://gitlab.gnome.org/GNOME/glib/-/issues/692"
	)

I noticed I wrote shared in the OP, edited.

[pierrejoye]

ah, that's no issue, we use the shared build only.

…

On Mon, Jan 3, 2022, 11:59 PM friendlyanon ***@***.***> wrote: What is the issue you are experiencing? https://github.com/conan-io/conan-center-index/blob/58a0fe0fcc0f9daaeaad35b22f75bc2c70e0d14c/recipes/glib/all/conanfile.py#L52-L56 — Reply to this email directly, view it on GitHub <#8618 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACE6KHKNC5P63MAYKNGLUTUUHIWLANCNFSM5LFR337Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[friendlyanon]

Okay, so it seems there is a bit of a cyclic dependency going on with Cyrus SASL and OpenLDAP.

The OpenLDAP project has a component called lmdb, which is necessary to build the sasldb plugin for Cyrus SASL and then OpenLDAP depends on Cyrus SASL for full functionality. Upstream Cyrus SASL also seems to be using some weird conan setup and ships VS solutions for Windows in the win32 folder, so that could be used on Windows hopefully.

There is also the ldapdb plugin in Cyrus SASL, which again depends on OpenLDAP and I'm not sure how to deal with that.
It seems that lmdb must be broken out into its own recipe at the very least.

cc @uilianries

Edit: okay, I forgot that lmdb already has a recipe, but I'm still unsure about the plugins.

[friendlyanon]

A convenient solution to libffi having a custom patch necessary for use in PHP is to use Barbarian.
This would allow us to stay in the Conan ecosystem without having to host an Artifactory server for custom recipes.

[Croydon]

A convenient solution to libffi having a custom patch necessary for use in PHP is to use Barbarian. This would allow us to stay in the Conan ecosystem without having to host an Artifactory server for custom recipes.

Unfortunately, this is not a solution as CCI recipes can only depend on other CCI recipes

[friendlyanon]

The goal is not to have php-src in CCI, but to have all its dependencies on CCI, so it can be built easily on all platforms once it has a CMake build tooling. For php-src, that's perfectly fine, since no other dependency has libffi as a dependency.

For php-src to be available on CCI as well, all of its dependencies that are patched and can't be upstreamed for various reasons would first have to be in a desirable condition upstream. Let's just say I don't want to go down that rabbit hole myself and Barbarian is a good enough solution in the meantime.

[Croydon]

The goal is not to have php-src in CCI, but to have all its dependencies on CCI, so it can be built easily on all platforms once it has a CMake build tooling. For php-src, that's perfectly fine, since no other dependency has libffi as a dependency.

Understood. I find it personally interesting to eventually have PHP itself in CCI too, but let's keep this out of this issue for now. Perhaps change the title of this issue to something like Dependencies of PHP?

Huge 👍 for working towers a CMake + Conan build system for PHP, btw. 👏