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.