On Sat, Apr 04, 2009 at 04:51:48PM -0700, Robin H. Johnson wrote: > On Sat, Apr 04, 2009 at 07:39:36PM -0400, Jeff King wrote: > > > +ifeq ($(wildcard $(PERL_PATH)),) > > I'm not sure what you're trying to accomplish with the wildcard, unless > > it is "PERL_PATH = /usr/*/perl" or similar, but that seems a bit crazy > > to me. It should probably behave the same as TCLTK_PATH, though (so if > > there is a good use case, TCLTK_PATH should be enhanced). > No. The ifeq ($(wildcard $(PERL_PATH)),) is entirely correct. > It's one of the few ways to detect the existence of a file from within > Make, without any exec calls. If you give it a non-expandable path, > /usr/bin/perl in this case, it checks only that path, and either returns > it or an empty string. This enables us to check that /usr/bin/perl > exists, and take suitable action if it does not. Ah, I see. You are not asking "was PERL_PATH blank" but rather "does PERL_PATH exist". And I think that is not the right thing for the Makefile, as it is unlike any other part of the git Makefile, which generally does what it is told with the minimum of magic. That sort of magic generally goes into configure.ac. > > I don't think there is a point in setting NO_PERL_MAKEMAKER if NO_PERL > > is set, and I believe the export is pointless, as I described in an > > earlier email. > From further down the Makefile: > ifdef NO_PERL_MAKEMAKER > export NO_PERL_MAKEMAKER > endif So NO_PERL_MAKEMAKER is _already_ exported, and I don't think there is any reason to export NO_PERL in the environment (see patch 4/4, which exports it via GIT-BUILD-OPTIONS). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
