[RFE] Generate a phar distribution

[remicollet]

Open for discussion. Mostly, only a proof of concept.

This will allow the have php-parse command as a single file.

$ build/makephar.sh 
Get version from changelog: 4.5.1-dev
phpab v4.5.0-2-g4bb33d9 - Copyright (C) 2009 - 2020 by Arne Blankerts and Contributors

Scanning directory lib

phar archive 'build/php-parse-4.5.1-dev.phar' generated.

$ php build/php-parse-4.5.1-dev.phar 
Must specify at least one file.

Usage: php-parse [operations] file1.php [file2.php ...]
...

Goal:

• use this phar instead of downloading the full sources in php-src
• add the phar file during the release process (as for pear)
• install the phar file in build like other needed tools

Problem to solved:

• allow to build php from sources, in offline environment

[remicollet]

Notice: build/php-parse.tpl is mostly bin/php-parse (- autoloader) + vendor/theseer/autoload/src/templates/ci/phar.php.tpl

phpab is a simple tool from @theseer already used by some project like phpunit.

[remicollet]

Ping @sgolemon as this is related to PHP 8 release process

[nikic]

Thanks for bringing this up, I have also been wondering about this. I think the main issue is that we may end up generating stubs even though nothing changed -- it really shouldn't be necessary for a PHP build to fetch PHP-Parser in any form (source or phar) if one is not actually modifying stub files.

As the timestamp based dependency tracking that Make uses is unreliable for this purpose (especially where release tarballs are concerned), maybe we should include a hash of the original file in the generated file and then skip processing (and loading of PHP-Parser) if it matches? Or maybe there is some simpler way?

[remicollet]

I think the main issue is that we may end up generating stubs even though nothing changed

Yes, or when we need to patch the stub... (well, in this case the patch should only includes the arginfo changes).

[remicollet]

As I still think having a single file can make usage simpler, also add the phar for the library (which can be included from gen_stub.php)

[nikic]

Overall, I'm not convinced that we need this. For the php-src use case, our current solution seems to work fine, and pretty much everyone else can use composer.

Adding a phar would complicate the release process, and that's something I'm not willing to do, unless it is fully automated (i.e. phar built by GA and attached to release). I don't think there are enough use cases to bother.