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
_______________________________________________
freebsd-doc@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-doc
To unsubscribe, send any mail to "freebsd-doc-unsubscr...@freebsd.org"
