Date: Mon, 27 Jan 2014 15:19:02 +0000 From: Alexey Dokuchaev <danfe@FreeBSD.org> To: Warren Block <wblock@wonkity.com> Cc: doc@freebsd.org, Pietro Cerutti <gahr@FreeBSD.org> Subject: Re: [patch] PH tells crap about GMAKE (Was: Re: svn commit: r340018 - head/textproc/scew) Message-ID: <20140127151901.GA80986@FreeBSD.org> In-Reply-To: <alpine.BSF.2.00.1401270514480.36906@wonkity.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140127151901.GA80986>