Add --with-regex=PATH build option#1974
Conversation
|
FTR: this build option is required to simplify MinGW cross-building of Squid for Windows. |
rousskov
left a comment
There was a problem hiding this comment.
@yadij, if you want to request my review, please do so via the Reviewers dialog on the primary GitHub PR page (rather than just changing PR labels). We have discussed that before: GitHub does not send notifications when labels are changed, and GitHub "your review is requested" search is unaware of our custom labels. Our custom labels serve a different purpose than requesting reviews!
| AC_CHECK_HEADERS([regex.h],,[LIBREGEX_LIBS=""]) | ||
| AC_CHECK_FUNCS([ \ | ||
| regcomp \ | ||
| regexec \ |
There was a problem hiding this comment.
AFAICT, official code makes REGEXLIB empty when regexec is not found in libregex.
PR code may1 set LIBREGEX_LIBS to -lregex when regexec is not found in libregex.
Is that change intentional?
This concern may be related to the current build failure (but it is valid even if that build failure is triggered by other/unrelated PR bugs):
/usr/bin/ld: cannot find -lregex: No such file or directory
Perhaps it would be better for this PR to continue to use existing AC_CHECK_LIB() check logic when (and only when) PKG_CHECK_MODULES fails? Doing so would make it clear that this PR preserves existing behavior in no-pc "last resort" cases (while relying on .pc to do the right thing in all other cases)?
Footnotes
-
The exact conditions for that "may" are not important for this question, but they include something like "no .pc file but regex.h is present". ↩
| AC_SUBST(REGEXLIB) | ||
| SQUID_AUTO_LIB(regex,[GNU Regex],[LIBREGEX]) | ||
| SQUID_CHECK_LIB_WORKS(regex,[ | ||
| PKG_CHECK_MODULES([LIBREGEX],[libregex],[:],[:]) |
There was a problem hiding this comment.
This PKG_CHECK_MODULES() addition means that, in environments with the corresponding .pc file, Squid no longer defaults to -lregex; Squid now defaults to whatever that .pc file dictates. Please mention this important change/improvement in release notes and commit message. It is more important than the added --with-regex support itself in many cases!..
A simple way to build with custom libregex paths instead of
forcing users to manually set build environment flags.
Currently only supports (re)implementations of GNU libregex.