update libwebp and libxml2 #982
Conversation
| '-DWEBP_BUILD_WEBPINFO=OFF', | ||
| '-DWEBP_BUILD_WEBPMUX=OFF', | ||
| '-DWEBP_BUILD_FUZZTEST=OFF', | ||
| SPCTarget::getLibcVersion() === '2.31' && GNU_ARCH === 'x86_64' ? '-DWEBP_ENABLE_SIMD=OFF' : '' // fix an edge bug for debian 11 with gcc 10 |
There was a problem hiding this comment.
Supporting pre-built content with optional feature is not safe though. Either use fixed features, or remove pre-built content.
There was a problem hiding this comment.
This specific feature set is fine with prebuilt archives. This is just a debian 11 gcc 10 bug where it's missing one single avx2 intrinsic when trying to build the library.
| '-DCXX_MAVX512VL_SUPPORTED:BOOL=FALSE' | ||
| ); | ||
| $cflags = getenv('SPC_DEFAULT_C_FLAGS') ?: getenv('CFLAGS') ?: ''; | ||
| $has_avx512 = str_contains($cflags, '-mavx512') || str_contains($cflags, '-march=x86-64-v4'); |
There was a problem hiding this comment.
Also not an issue unless we were to build prebuilt packages with avx512 support, but then most people wouldn't be able to run them.
This exact same check is already used in every single extension, adding it for a library doesn't prevent prebuilt archives.
| if (!file_exists($this->source_dir . '/config.m4') && is_dir($this->source_dir . '/source/pdo_sqlsrv')) { | ||
| FileSystem::moveFileOrDir($this->source_dir . '/LICENSE', $this->source_dir . '/source/pdo_sqlsrv/LICENSE'); | ||
| FileSystem::moveFileOrDir($this->source_dir . '/source/shared', $this->source_dir . '/source/pdo_sqlsrv/shared'); | ||
| FileSystem::moveFileOrDir($this->source_dir . '/source/pdo_sqlsrv', SOURCE_PATH . '/pdo_sqlsrv'); | ||
| FileSystem::removeDir($this->source_dir); | ||
| FileSystem::moveFileOrDir(SOURCE_PATH . '/pdo_sqlsrv', $this->source_dir); |
There was a problem hiding this comment.
We could do it with extract hook. It's not patch.
There was a problem hiding this comment.
Yes, agreed, that's better.
|
Speaking of which, I haven't set up any new command-line override rules for 3.0 yet. Besides the currently limited custom-url, custom-git, and custom-local options, what good methods do you think could be used to design a command-line overriding way? The current version 3.0 (dev) allows users to register additional registry entries to override basic configs to let someone wants to override or expand functions on top of them. I don't know if it makes sense to continue expanding Making another |
|
I would say we scrap the custom url thing entirely and instead give users an option to add a second source.json? We should chat about what features we no longer want to support and what we want to rework. |
All the implementation I made has been committed to the v3-dev branch. The refactoring status is in #980 . If you have any other ideas, free to leave a message on Discord or submit a new RFC. |
What does this PR do?
This was what is required to build php 8.5 extensions (with 4 overridden source urls) by static-php/packages: see https://github.com/static-php/packages/blob/c5f504b532e394bd54391fa47501d7d07c6b03ee/config/templates/craft.yml.twig#L51