Details

Normalize deployment tools usage and definitions by putting into one place instead of sprinkling them out over many disjoint files. This is a follow-up to achieve the same goal in an incomplete rev.348521.

I am not really keen on adding yet another top level .mk file that sets command names, much of this is caused by scatering etc/Makefile contents and rules about the tree when it was and should of been maintained as the one place for all of this and simply called as a submake. Perhaps it makes since anymore, perhaps not. But certainly having INSTALL and INSTALL_CMD default to and 99.999% of the time be "install" is not a good idea, same for MTREE and MTREE_CMD, they are being used in mixed manners, this needs to be sorted out asap and just use
MTREE_CMD and untwist some of this MTREE overload that should really overlaod MTREE_CMD.

Anyone having recersion issues with this? I know it well work but now we are overloading what MTREE_CMD is to mean. Is it the command only "mtree", or is it the command with the flags?

I am also pretty sure this IMAKE_foo and all the related DESTDIR/WORLDTMP stuff should be pushed back down in etc/Makefile and not be in this Makefile.inc1. That would also push and cleanup much of the related stuff here.

Please no, MTREE is used elsewhere, the original source of this stuff here infact, and is the list of etc/mtree/* files that are to be processed. And again 2 variables that end up being "mtree" should always be colapsed to 1 variable. MTREE was already taken, the correct variable for this is then MTREE_CMD and MTREE has another meaning.

Actually Makefile and .mk files generally fall under the rule of "receipes" and are not copyrightable, though it seems as sjg/Juniper has asserted copyrights on some of them, which could be challenged and possibly removed. This new file could still use a header.

Well, unlike original commit this change deliberately added INSTALL_CMD for consistency with other tools. The expectation is that XYZ_CMD might be something one can fiddle with, while XYZ could be whatever build system needs to do its magic.

@rgrimes Well, it's not that we need indirection, it's just I think because sys.mk is kinda self-contained (or pretends to be anyway), so it contains its own (re-)definition of pretty much every tool under the sun. It's probably for a good reason to allow compiling out-of-the tree kmods. I did not feel brave enough to add .include src.tools.mk in there, so this is a quick way to make it obey and use proper override when we are doing installkernel.

I respectfully disagree with this. The whole point of having MAKE_CMD is that it should never be thrown away, especially in a file that might be included into other places. If the build system needs to use something else for a particular target (${WORLDTMP}/legacy/usr/sbin/mtree) at some point, it then should construct a new variable out and use that. I've renamed variable to clarify its scope.

I need to think through the sys.mk change, and I've got no time today to do that. I'll try to articulate something coherent (one way or the other) by the end of the day tomorrow since I know what I've said so far isn't actionable.

sys.mk is read before anything else, so ?= is often meaningless unless a makefile read by sys.mk has already set a value, or a parent has exported a value to environment.
Of course we do support local*sys.mk so this can work.
If the indirection is desired, then as bapt says a single line would be neater

Yea, that's why... I just came to that conclusion after looking at something else. I concur: let's change this to babt's one liner because it could work because it isn' until ${INSTALL} is expanded do we also expand ${INSTALL_CMD:Uinstall}.