add --with-frankenphp-app=/path/to/app option

[henderkes]

What does this PR do?

@dunglas I hope this is the idiomatic way to achieve this?

Checklist before merging

@crazywhalecc adding frankenphp as a library is a bit of a dirty hack to depend on the source to be downloaded. better ideas?

[crazywhalecc]

No better idea too, unless we implement fetch-on-build. If the frankenphp pull barely affects your normal non-frankenphp builds, then I think that's acceptable.

However, if you want to implement fetch-on-build for frankenphp alone, you could just add it as a source and then manually call Downloader before processFrankenphpApp.

[henderkes]

I thought about fetch-on-build, but then remembered that you wanted to keep all network calls and downloads in the download stage (which makes sense, github release fetching is surprisingly prone to failure).

Frankenphp source is fairly small, I think it's acceptable too.

[crazywhalecc]

Will we still use dunglas ?

[crazywhalecc]

How about processing frankenphp app before building everything? Although I don't have any build requirements for frankenphp embed app, but if something goes wrong here, it would be annoying to wait for dozens of minutes to build and then report an error.

[crazywhalecc]

Will we still use dunglas ?

[henderkes]

Will we still use dunglas ?

@dunglas not sure about plans to switch the go package name. The frankenphp.dev PR has been active for months.

[dunglas]

Currently yes, we still use dunglas. It may be possible to migrate thanks to Go 1.25, which fixed some issues blocking the migration, but I didn't have the time to take another look and it's low priority TBH.

[henderkes]

We could instead change --with-frankenphp-app use an app.tar inside the current directory? That way we could solve the docker conondrum.

Otherwise, just don't support this in docker?

[crazywhalecc]

Otherwise, just don't support this in docker?

I think passing it in via environment variables would be more feasible. We could mount the directory in the spc-docker script and then pass the replaced value to docker. In this way, even if we don't want to implement it for docker, we can leave the docker script alone.

But, this ultimately depends on how the majority build FrankenPHP.

adding frankenphp as a library is a bit of a dirty hack to depend on the source to be downloaded. better ideas?

Off-topic, considering that we'll be building different SAPIs as separate packages in the upcoming v3, and frankenphp is more independent than other SAPIs, perhaps we can first consider whether it can be simply separated into build:frankenphp and build:libphp. This is on my list and I'll announce it soon.

[henderkes]

Something with the --with github.com stuff replacement isn't working quite right. I get a freestanding /caddy at the end.

[henderkes]

@crazywhalecc can you try if this works on mac? If it's working, it should be ready for merge.

[crazywhalecc]

It's simple chage and I've done it. I'm really not a fan of patching arguments like this, but I think the same thing will need to be done sooner or later in version 3.0.