mirror of
https://github.com/php/pftt2.git
synced 2026-03-24 09:12:17 +01:00
Read PHPBuild Version from Production version stored in php.exe executable file #25
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @hollyhuiLi on GitHub (Jun 3, 2019).
The php product version can be read through JNA with Version utilities.
@weltling commented on GitHub (Jun 4, 2019):
Thanks for bringing this up. I'm not sure we really should spend time on this. Firstly - when setup is fixed,
phpinfo()should be fine. Secondly - there's also scenarios for PHP as Apache module. In that case, it'll need to be read from the DLL probably. On the other hand,phpinfo()is the most simple and unified way to do that. Or is there perhaps any other reason to change this piece?Thanks.
@hollyhuiLi commented on GitHub (Jun 4, 2019):
Thanks for the comment @weltling. What you said make sense. Since currently we only setup on Windows VM, how about we change it just for windows?
@cmb69 commented on GitHub (Jun 4, 2019):
The other scenarios @weltling mentioned are also for Windows. For the Apache module scenario, there is no php*.exe involved, but rather the php7.dll.
@weltling commented on GitHub (Jun 4, 2019):
@hollyhuiLi but we don't really buy anything with this. Different flavors will probably need different handling. Right now we only test CLI, but FCGI and Apache are to come as well. I'd really suggest to keep it as is, a setup fix is much more convenient for this.
Thanks.
@hollyhuiLi commented on GitHub (Jun 4, 2019):
@weltling, OK let's hold the change of the PHPBuild version at this point. For the setup fix, just want to double confirm our plan: Since PHP version is problematic at that point, it seems we want to simply check and install the latest VCRedist without touching the PHP build.
@weltling commented on GitHub (Jun 5, 2019):
@hollyhuiLi exactly. Setup should pre-install anything needed for the tool to run and flag successful setup. The tool is expected to be able to run any PHP version it supports on the same test host. At the runtime it would be only to check whether the setup has ensued and bail out if not. When it needs to re-setup, say a new feature added, the tool would override the setup flag and set it again when re-setup finished. So when a test run is executed, it should not care about installing anything, it should expect everything is prepared. If there are any fails like in this case
phpinfo(), those would either be attributed to a broken setup or to an issue in PHP. Having the PHP version at the setup time seems not necessary therefore, as a concrete test run can use any supported PHP version.Thanks.
@cmb69 commented on GitHub (Oct 10, 2019):
Okay, I think this issue doesn't need to be addressed, so I'm closing the ticket. Thanks.