On Tue, May 2, 2017 at 10:51 PM, Kevin Daudt <me@xxxxxxxxx> wrote: > On Tue, May 02, 2017 at 08:52:21PM +0200, Ęvar Arnfjörš Bjarmason wrote: >> >> * Due to the bizarro existing semantics of the configure script noted >> upthread if you have a git build script that does --with-libpcre & you >> have libpcre1 installed, it'll link to it, but now since >> --with-libpcre defaults to libpcre2 it'll silently skip linking to it >> if you don't have it installed. >> > > Case in point: The Archlinux git-git aur package[0] (community maintained, > latest git version) does run ./configure without --with-libpcre, but > requests it from make with USE_LIBPCRE=1. > > I noticed when trying git grep -P which then failed. > > [0]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=git-git Whatever's going on there is unrelated to the issue I'm talking about, but if that's producing a package where -P doesn't work that looks like a bug in the Makefile. The way --with-libpcre works now is that it second guesses you, i.e. it'll put USE_LIBPCRE=YesPlease into config.mak.autogen (sourced by the Makefile) only if you supply --with-libpcre *and* it can find a working libpcre on the system, otherwise it silently ignores you. Whatever you supply to the configure script it'll be overridden by Makefile arguments if present, but even if there was another bug where ./configure arguments took precedence over Makefile arguments I don't see how it would apply here, in this case nothing libpcre related will be written to config.mak.autogen. So I must be missing something. I don't see how that package build doesn't either fail at compile time because it doesn't have pcre, or work, in which case the -P option will work.