Feat/pgo v3#1138
Conversation
|
StaticPHP Test Bot Detected: Extensions: |
|
(I tested with static-php/packages v3 branch, php 8.5 zig on rpm. Tests with Alpine and gcc are still to finish in a few hours when ci runs.) |
|
Wair, why is curl a target like php and not a package/library? We don't compile the exe right? |
We could compile curl.exe, which shows that StaticPHP is not only suitable for building static PHP, but also for other projects. Just like we already support building pkg-config and re2c. Making them targets simply makes reasonable.
|
…ith different pkg_root_path set
…fined behaviour sanitizer)
Okay, added curl.exe on Windows too. Also figured out the root cause of the BUILD_CC patch minilua crash (zigs undefined behaviour sanitizer tripping up, if you run |
|
Oh, there's even an issue running the binaries despite no undefined sanitizer that I can't reproduce locally or in docker. Very weird. |
|
It's working as intended now, but compiling llvm binutils is really taking quite some time. We should host a prebuilt package for that and use that regardless of whether the user prefers prebuilts or not, there's no reason to rebuild this. It's static (always compiled with -musl) per arch-os. I tried downloading llvm tarball instead, but GitHub gives me such a bad connection here in SEA that the wait time is too ridiculous. |
Just add a workflow in |
😞 Singapore VPN has the best speed accessing GitHub for me. |
| <?php | ||
|
|
||
| declare(strict_types=1); | ||
|
|
||
| namespace StaticPHP\Doctor\Item; | ||
|
|
||
| use StaticPHP\Attribute\Doctor\CheckItem; | ||
| use StaticPHP\Attribute\Doctor\FixItem; | ||
| use StaticPHP\Attribute\Doctor\OptionalCheck; | ||
| use StaticPHP\DI\ApplicationContext; | ||
| use StaticPHP\Doctor\CheckResult; | ||
| use StaticPHP\Package\PackageInstaller; | ||
|
|
||
| #[OptionalCheck([self::class, 'optionalCheck'])] | ||
| class GoXcaddyCheck |
There was a problem hiding this comment.
Is there any reason that we must check go-xcaddy in doctor check?
There was a problem hiding this comment.
not strictly necessary, but it makes things like pre building images by just running doctor a bit easier. you can remove it if you want
There was a problem hiding this comment.
Oh, I did forget to consider the base image in v3. But for FrankenPHP, I think it's easy to just run bin/spc install-pkg go-xcaddy after the doctor command.
| */ | ||
| public function stripBinary(string $binary_path): void | ||
| { | ||
| $strip = ApplicationContext::tryGet(ToolchainInterface::class) instanceof ZigToolchain |
There was a problem hiding this comment.
for some reason the DI library you're using returns "true" for ->has even if the class is in fact not autowirable
| return null; | ||
| } | ||
|
|
||
| private function reconcilePhpSrcVersion(): void |
There was a problem hiding this comment.
This solution seems too wild, and I don't think it is appropriate here.
| if ($source_downloaded && $artifact->getName() === 'php-src' && ($requested = $this->getOption('with-php'))) { | ||
| $info = ApplicationContext::get(ArtifactCache::class)->getSourceInfo('php-src'); | ||
| $cv = $info['version'] ?? null; | ||
| $ct = $info['cache_type'] ?? null; | ||
| $matches = $requested === 'git' ? $ct === 'git' : ($cv !== null && $ct !== 'git' && ($cv === $requested || str_starts_with($cv, $requested . '.'))); | ||
| if (!$matches) { | ||
| $source_downloaded = false; | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
you want to try to switch PHP versions simply by changing --with-php?
There was a problem hiding this comment.
Yes, --dl-with-php switches the php version in the build command, or spc download --with-php=.. switches the php version too. We shouldn't use the old version in source/php-src when the user explicitly switched it.
Even better would be to have different trees for different php versions (php-src-8.2, ... , php-src-8.5), that would simplify the switch more, but it's a larger refactor.
Edit: v2 already did this with the source dir stale logic. In v3 it kept rebuilding the old php versions even after switching.
There was a problem hiding this comment.
Ah, I think I need to look into that. I previously designed a separate command to achieve this bin/spc switch-php-version. I have not considered using --with-php to switch it directly.
There was a problem hiding this comment.
Anyway hardcoding looks strange in ArtifactDownloader and PackageInstaller, and I'll take a look at how to fix it later.
There was a problem hiding this comment.
Ah, could you also add llvm-tools to static-php/hosted? We only need a x86-64 and an aarch64 version for linux (any maybe macOS in the future, pending m5 mini availability next month). They are linked statically (musl target, like all packages) and only update when zig version updates.
There was a problem hiding this comment.
Of course, but let's take them one by one first 🤯 There's so much to do before releasing the first alpha version.
|
wtf I have no idea what failed in the tests and why. it passes locally and looking for php-config there makes no sense, neither of the new extensions does it |
|
had claude pull everything and this is what it thinks the problem is with CI I'll get a PR up with the fix and we'll see if it's right |
mongo-php-driver 2.3.3 added a config.m4 check that falls back to
php-config when PHP_VERSION_ID is unset in the shell env. In-tree
PHP source builds have no php-config, so configure fails with:
checking PHP version... configure: error: php-config not found
Set PHP_VERSION_ID from main/php_version.h before configureForUnix
so the lookup short-circuits.
… (bleeds libpq polyfills into php configure, poisoning e.g. have_strlcat results)
|
(current CI failures are because I didn't forward the temporary fixes for fastchart and clickhouse extensions, iliaa will probably release versions with my fixes upstreamed in a few days) |
|
I'd like to merge some easily split parts of this branch into v3 first, so that the branch doesn't become too large and make reviews troublesome. |
|
Yes, I'm getting to a point where building static-php/packages based on this branch is possible. The majority of changes here are really just behaviour fixes that can be applied independently. |
What does this PR do?
Checklist before merging
*.phpor*.json, run them locally to ensure your changes are valid:composer cs-fixcomposer analysecomposer testbin/spc dev:sort-configsrc/globals/test-extensions.php.extension testortest extensionsto trigger full test suite.