Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add PHP_BUILD_DATE constant #16747

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add PHP_BUILD_DATE constant #16747

wants to merge 1 commit into from

Conversation

cmb69
Copy link
Member

@cmb69 cmb69 commented Nov 10, 2024

This information can be occasionally useful, and would otherwise need to be parsed from phpinfo() output.

However, maybe more importantly we unify the build date between what is given by php -v and php -i, since these compilation units are not necessarily preprocessed within the same second.


This came up in #16560. While I don't mind a new PHP_BUILD_DATE constant, for me it's more important to unify the dates.

Note that I'm not sure if the format is standardized; I believe so, though. The test will show.

This information can be occasionally useful, and would otherwise need
to be parsed from `phpinfo()` output.

However, maybe more importantly we unify the build date between what is
given by `php -v` and `php -i`, since these compilation units are not
necessarily preprocessed within the same second.
@bukka
Copy link
Member

bukka commented Nov 10, 2024

Isn’t this going to be problematic for reproducible builds?

@cmb69
Copy link
Member Author

cmb69 commented Nov 10, 2024

Isn’t this going to be problematic for reproducible builds?

Well, we have this anyway (not the constant, but using __DATE__ and __TIME__). Either we drop that altogether, or we maybe we want to make it configurable.

@bukka
Copy link
Member

bukka commented Nov 11, 2024

So I have done a little bit checking and it's actually fine as both clang (16+) and gcc (7+) will set __DATE__ and __TIME__ macros from SOURCE_DATE_EPOCH env var during the build. There were actually issues in past where those two were problematic (before the SOURCE_DATE_EPOCH support in compilers) but it should be all good now.

@bukka
Copy link
Member

bukka commented Nov 11, 2024

The reason why I mentioned it before is that if DATE and TIME were not safe for repro builds, then it wouldn't be a good idea to expose it as user space constant. But that's not the case so all good. :)

@bukka bukka removed the ABI break label Nov 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants