maint: introduce LintMan to aid on tracking/updating values and fix pcre2limits.3 for the correct name length #776
Conversation
carenas
force-pushed
the
lintman
branch
2 times, most recently
from
4be5b05 to
ad5b086
Compare
|
I like it! Thanks! Is it possible to call LintMan from the UpdateAlways script. Otherwise, we'll never remember to check it. |
Allow tagging the documentation with a `#define` value that could be then updated programmatically. Update the value for MAX_NAME_SIZE in pcre2limits.3 that was missing since ced3b0f (Increase name length to 128, 2024-03-11) and while at it, improve on its description and add a tag for a related variable. For completeness, add also a tag to the same value in pcre2pattern.3 and the configuration for VMS that was missing since 6c670c7 (Update overlooked cmake update of name size to 128, 2024-03-11) and add it to UpdateAlways so it can be used in a developer tree.
|
Since it modifies the repository and requires a configured tree it is more suitable for a manual run in a developer tree (maybe as a pre-push hook if you want to automate the checks). Goes without saying that changes to the tree it does, should be committed or discarded (if not relevant) and that is better done by a human IMHO, but had added it to the script in a way that is safe for the CI use of it as requested. |
| my $file; | ||
| my %defs; | ||
|
|
||
| foreach $file ("../src/config.h.generic") |
There was a problem hiding this comment.
I made one change here. If the user configures their PCRE2 differently, they should still (probably) get the same documentation is everyone else?
I've made the docs match the generic config. Users don't receive the maintainer scripts in maint/ as part of a tarball release, so they won't be customising the values in the docs for their installation anyway.
Finally, I've checked that it's running nicely in CI - and it seems to work well. Great!
There was a problem hiding this comment.
but isn't config.h.generic created by the Makefile?
in that scenario, if a new setting is added to the documentation then this will break CI, right?
There was a problem hiding this comment.
Well, if you want to reference a new constant using your .\" DEFINE syntax then it has to be defined in config.h. That's not really changed from what you did. config.h.generic is just an exact copy of config.h when you run ./configure with no arguments, so the two config files always have the same constants in.
There was a problem hiding this comment.
but I only change config.h.in, and configure creates config.h, and after make runs then config.h.generic is created from it.
but the CI checks for that last file, which hasn't been updated yet because configure and make didn't run yet, right?, and when LintMan runs finds a DEFINE that doesn't exist in that file and dies.
There was a problem hiding this comment.
CI ensures that config.h.generic is kept up to date.
2 participants
Correct a minor issue with the documentation/configuration and introduce a tool to help prevent similar issues in the future.
The tracking is not intrusive (meaning that the documentation is still valid nroff) and independent of the build system, but I am curious on comments and alternatives or where it fits in the development process.