On Tue, Apr 11, 2017 at 12:35 PM, Jeff King <p...@peff.net> wrote: > On Sat, Apr 08, 2017 at 01:25:04PM +0000, Ævar Arnfjörð Bjarmason wrote: > >> Change the internal USE_LIBPCRE define, & build options flag to use a >> naming convention ending in PCRE1, without changing the long-standing >> USE_LIBPCRE Makefile flag which enables this code. >> >> This is for preparation for libpcre2 support where having things like >> USE_LIBPCRE and USE_LIBPCRE2 in any more places than we absolutely >> need to for backwards compatibility with old Makefile arguments would >> be confusing. >> >> In some ways it would be better to change everything that now uses >> USE_LIBPCRE to use USE_LIBPCRE1, and to make specifying >> USE_LIBPCRE (or --with-pcre) an error. This would impose a one-time >> burden on packagers of git to s/USE_LIBPCRE/USE_LIBPCRE1/ in their >> build scripts. >> >> However I'd like to leave the door open to making >> USE_LIBPCRE=YesPlease eventually mean USE_LIBPCRE2=YesPlease, >> i.e. once PCRE v2 is ubiquitous enough that it makes sense to make it >> the default. > > Yeah, I think it's nice to keep the build-time knobs compatible. In the > long run I assume we'll want to add a USE_LIBPCRE1 flag and USE_LIBPCRE > just becomes a synonym for it (in fact, we could do that in this > commit).
I could just add that. Hints for how to do that without entirely copy/pasting the "ifdef USE_LIBPCRE" in the Makefile welcome. The Makefile syntax doesn't support some form of "ifdef X || ifdef Y" AFAICT, so it looks like I'll need to copy those lines... > I suspect we won't ever want to make it a synonym for USE_LIBPCRE2. > Unlike the run-time synonyms, where the expressions themselves are > backwards compatible, builders need to care which one they're using. Maybe, that's a problem for another day, at some point we might want to turn PCRE on by default, and then maybe v2 will be prolific enough to make that the default...
