From owner-freebsd-doc@FreeBSD.ORG  Mon Jan 27 15:19:02 2014
Return-Path: <owner-freebsd-doc@FreeBSD.ORG>
Delivered-To: doc@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 1033)
 id 03204442; Mon, 27 Jan 2014 15:19:02 +0000 (UTC)
Date: Mon, 27 Jan 2014 15:19:02 +0000
From: Alexey Dokuchaev <danfe@FreeBSD.org>
To: Warren Block <wblock@wonkity.com>
Subject: Re: [patch] PH tells crap about GMAKE (Was: Re: svn commit: r340018
 - head/textproc/scew)
Message-ID: <20140127151901.GA80986@FreeBSD.org>
References: <201401170910.s0H9Aw9O087448@svn.freebsd.org>
 <20140117093546.GA16656@FreeBSD.org>
 <20140117095020.GD4006@gahrfit.gahr.ch>
 <20140117141440.GA94157@FreeBSD.org>
 <alpine.BSF.2.00.1401240922210.87046@wonkity.com>
 <alpine.BSF.2.00.1401251735370.2111@wonkity.com>
 <20140127085527.GA84465@FreeBSD.org>
 <alpine.BSF.2.00.1401270514480.36906@wonkity.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.BSF.2.00.1401270514480.36906@wonkity.com>
User-Agent: Mutt/1.5.22 (2013-10-16)
Cc: doc@freebsd.org, Pietro Cerutti <gahr@FreeBSD.org>
X-BeenThere: freebsd-doc@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Documentation project <freebsd-doc.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-doc>,
 <mailto:freebsd-doc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-doc/>
List-Post: <mailto:freebsd-doc@freebsd.org>
List-Help: <mailto:freebsd-doc-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-doc>,
 <mailto:freebsd-doc-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jan 2014 15:19:02 -0000

On Mon, Jan 27, 2014 at 05:17:47AM -0700, Warren Block wrote:
> Okay, final version of that paragraph:
> 
>         <para>Several differing <literal>make</literal>
>           implementations exist.  Ported software often requires a
>           particular implementation, like <acronym>GNU</acronym>
>           <command>make</command>, known in &os; as
>           <command>gmake</command>, or <command>fmake</command>, the
>           legacy &os; <command>make</command>.</para>

I might be nit-picking, but "GNU make" constitutes its own software name,
i.e. first <command>make</command> is not really about the command, it is
part of the name (GNU make).

> One last question, and I'll commit this.  The last sentence in this
> paragraph: [...]
> 
> It's not really clear what the last sentence is trying to say.  Is it
> saying that I might need to modify application Makefiles with MAKE_CMD?

No; application Makefiles should always use ${MAKE} (or, in GNU syntax,
$(MAKE) -- they don't like curly braces for some reason).

> Is it a warning that using MAKE_CMD in the port Makefile is probably a
> mistake?

On the contrary: since port's Makefile is parsed with FreeBSD make(1),
regardless of implementation thereof, any time it needs to reference
"down-stream" make(1) implementation (that is, expected by the ported
software), ${MAKE_CMD} should be used: depending of USES, MAKE_CMD is
set correctly to "gmake" or "fmake".  MAKE_CMD has nothing to do with
Ports Framework on its own.

Basically:

1) some software foobar, written by Linux junkie who knows nothing about
portability; he expects that every make is GNU make.  He has a regression
target in his Makefile that is not called by default; we do:

  USES=	gmake
  ...
  regression-test:
	${MAKE_CMD} -C ${WRKSRC} regression

Because with default make(1), it will fail: it expects GNU make, hence
we call it vie MAKE_CMD.

But!

2) Some guy does not know that subsequent makes should be called as $(MAKE);
we do (very rough example):

  post-patch:
	@${REINPLACE_CMD} s,make,$$(MAKE),' ...

MAKE is special variable, it should *never* be set explicitly (imake-ports
do it, but that's evil and should be fixed).

If it's still unclear, I'm happy to elaborate further.

./danfe