On Tue, 2011 Dec 6 16:26-0700, Eric Blake wrote:
>
> Yes, since we already do other configure checks for make capabilities,
> and substitute that into Makefile.in when producing Makefile. And no
> one said we have to run all the checks on all the platforms - it may
> be sufficient to detect multiple features on a single make probe run,
> at least for GNU make, to minimize forking in the common case.
That would help, surely. But I don't see why you would want to add yet
another moving part if there were a way to avoid it. I mean, if $({})
violated POSIX, or there were known implementations that could not
tolerate curlies, then sure. But the concerns that have been expressed
here are basically stylistic in nature, and while I don't disregard
those, I would think they're not nearly as important.
As far as I can see, this is on par with using "test $? != 0" instead of
-ne, or expr(1) instead of $((...)). Yes, it's less pretty, but it runs
on more systems than the pretty code. And isn't that what really
matters, at the end of the day?
> The user is already obligated to run the same make that was on the
> PATH when they ran configure, or to run './configure
> MAKE=/path/to/make' to hard-code their preference of make. Automake
> already generates Makefile.in that has substitutions that are implementation-
> specific; for example, see how @SET_MAKE@, @am__include@, @am__quote@,
> and so forth are hard-coded to the make implementation detected at
> configure time.
I was vaguely aware of SET_MAKE, but I didn't know that using the same
make program as configure detected was a basic premise of the system. I
retract that critique, then.
--Daniel
--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
