Branch: refs/heads/blead
Home: https://github.com/Perl/perl5
Commit: a52b628335bbf66bffef8b9cc1f18876d15d039c
https://github.com/Perl/perl5/commit/a52b628335bbf66bffef8b9cc1f18876d15d039c
Author: Craig A. Berry <[email protected]>
Date: 2026-07-18 (Sat, 18 Jul 2026)
Changed paths:
M MANIFEST
M autodoc.pl
A t/porting/check_config_defines.t
Log Message:
-----------
Make rogue defines in config.h fail a test, not break the build
9dc6550 made variables in config.h that are not documented in
config_h.SH into fatal errors rather than warnings. That broke the
build on VMS, which has relied heavily for 25+ years on the ability
to simply write #define statements directly into config.h before
config.sh is processed via config_h.SH.
The ostensible reason for adding lines directly to config.h was a
command line length limit of 255 characters, making it impossible
to simply stack up -D parameters willy nilly. There have also been
cases where new variables were added to Configure without first
defining them in config_h.SH and configure.com just tracked what
Configure was doing but never got updated when the variables were
documented. And there have probably been cases it was simply a
quick and convenient place to get something working.
It's fine to revisit all of that (command lines can be a lot longer
now) but there are over a dozen variables whose definitions would
need to be done differently. To test the related changes, it will
be necessary to do a lot of builds, at least one for each attempt
to fix each variable; that ain't gonna happen if autodoc.pl stops
the build in its tracks when it encounters a variable not defined
by the now-canonical process.
So it seems more appropriate to make this a failing porting test
than to stop the build, though variables defined in config_h.SH but
without documentation will still do that.
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
