Hi Ævar, On Tue, 2 May 2017, Ævar Arnfjörð Bjarmason wrote: > On Tue, May 2, 2017 at 2:09 PM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > > > On Sun, 30 Apr 2017, Junio C Hamano wrote: > > > >> * ab/grep-pcre-v2 (2017-04-25) 20 commits > >> - SQUASH??? > >> - Makefile & configure: make PCRE v2 the default PCRE implementation > >> - grep: remove support for concurrent use of both PCRE v1 & v2 > >> - grep: add support for PCRE v2 > >> - grep: add support for the PCRE v1 JIT API > >> - perf: add a performance comparison test of grep -E and -P > >> - grep: change the internal PCRE code & header names to be PCRE1 > >> - grep: change the internal PCRE macro names to be PCRE1 > >> - test-lib: rename the LIBPCRE prerequisite to PCRE > >> - grep: make grep.patternType=[pcre|pcre1] a synonym for "perl" > >> - grep & rev-list doc: stop promising libpcre for --perl-regexp > >> - log: add -P as a synonym for --perl-regexp > >> - log: add exhaustive tests for pattern style options & config > >> - grep: add a test for backreferences in PCRE patterns > >> - Makefile & configure: reword outdated comment about PCRE > >> - grep: remove redundant `regflags &= ~REG_EXTENDED` assignments > >> - grep: remove redundant regflags assignment under PCRE > >> - grep: submodule-related case statements should die if new fields are added > >> - grep: add tests for grep pattern types being passed to submodules > >> - grep: amend submodule recursion test in preparation for rx engine testing > >> > >> PCRE2, which has an API different from and incompatible with PCRE, > >> can now be chosen to support "grep -P -e '<pattern>'" and friends. > > > > FWIW for quite a couple of recent builds, `pu` fails on Windows with a > > variation of this error: > > > > CC blob.o > > In file included from revision.h:5:0, > > from bisect.c:4: > > grep.h:16:19: fatal error: pcre2.h: No such file or directory > > #include <pcre2.h> > > ^ > > compilation terminated. > > > > Maybe this can be fixed before hitting `next`? > > This will be due to a combination of the build machine not having pcre > v2 (but having v1) & my "Makefile & configure: make PCRE v2 the > default PCRE implementation" patch, which makes v2 the default for > USE_LIBPCRE=YesPlease. > > Is it easy to install v2 on these build machines? Alternatively that > patch could be ejected out of pu, or you could USE_LIBPCRE1=YesPlease > to use v1, but as explained in that commit I think it makes sense to > make v2 the default. Let me put it this way: Installing PCRE v1 in MSYS2 is as easy as pacman -Sy mingw-w64-x86_64-pcre To install PCRE v2, you would have to copy-edit https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-pcre/PKGBUILD, make sure that it builds by running it through makepkg-mingw -s possibly initializing a Git repository in the mingw-w64-pcre/src/${_realname}-${pkgver}/ directory, patching the source until it builds, committing the changes, adding them as patch files to the same directory as the new PKGBUILD, adjusting the PKGBUILD file to list the patch files with their checksums and to add the commands to apply them. Then (and this is a one time cost, fortunately) initializing two packages on BinTray (which we use to serve the Pacman packages of Git for Windows), then build and upload the packages. In short, PCRE v2 would be slightly (ahem, ahem) more involved than PCRE v1. I cannot imagine that MSYS2 is the only environment with that issue. Ciao, Dscho