On 01/03/2013 11:22 PM, Eric Blake wrote: > On 01/03/2013 03:10 PM, Stefano Lattarini wrote: >> On 01/03/2013 10:54 PM, Eric Blake wrote: >>> Based on a suggestion from Bob Friesenhahn: >>> https://lists.gnu.org/archive/html/bug-automake/2013-01/msg00017.html >>> >>> * doc/install.texi (Defining Variables): Mention that MAKE >>> can be overridden, and the caveats that come with setting it. > >>> +Another variable to be aware of is @env{MAKE}; many packages allow this >>> +to be set during @command{configure} in order to request the use of an >>> +alternative @command{make} implementation (such as GNU make, which is >>> +often present as @command{gmake}). However, once an alternative is >>> +chosen, the resulting Makefile may no longer work with the generic >>> +@command{make}, so you must make sure to consistently use your >>> +alternative make. >>> + >> s/make/@command{make}/? > > Or maybe s/make/$MAKE/? > Yes, likely clearer. But shouldn't that be s/make/@code{$MAKE}/ ? :-)
>> >> Apart from that possible nit, ACK from me. > > I'll see if anyone else chimes in with a wording suggestion in the next > 24 hours or so, then push. We will then see if the gnulib autoupdate > picks it up, or if I will have to give it a kick to find the new INSTALL. > OK. Thanks, Stefano
