Makefile.inc1: push /usr/libexec into the BPATH/TMPPATH

[kevans]

Summary

${WORLDTMP}/legacy/usr/libexec will only have libexec/ bits that we've pushed as bootstrap tools, so this is generally safe to include prior to PATH. The following are the ramifications of this change:

• BPATH addition gets us at least bootstrap flua in WMAKEENV path for buildenv, for those earlier systems where it's bootstrapped still (< CURRENT)
• TMPPATH addition gets the host flua path into WMAKEENV for !BUILD_WITH_STRICT_TMPPATH (the default) buildenv
• Reworked the sysent target to just set PATH and let it get worked out in src.lua.mk or individual sysent makefiles -- this gives us back the ability to overwrite LUA_CMD and use a different/external lua for these targets

[brooks]

LTGM. Adding Alex in case he has concerns about bootstrapping on MacOS/Linux.

[imp]

LGTM

[arichardson]

LGTM. Only concern might be that adding /usr/libexec to PATH adds too much stuff.

Hopefully I can get the strict tmppath usable by default soon so it shouldn't matter anymore then.

[kevans]

In D22464#491409, @arichardson wrote:

LGTM. Only concern might be that adding /usr/libexec to PATH adds too much stuff.

Hopefully I can get the strict tmppath usable by default soon so it shouldn't matter anymore then.

Yeah, so what I really wanted here with flua was some way to indicate that flua can/should be symlinked in from the host (preferably to the same location that I've added to BPATH) on the versions it's *not* being bootstrapped (__FreeBSD_version after I added it) to simplify this, since I don't really want to add /usr/libexec. Any advice on making that happen (or just getting flua into one of the standard BPATH/XPATH paths while leaving it installing to /usr/libexec) is quite welcome. =)

[arichardson]

In D22464#491412, @kevans wrote:

In D22464#491409, @arichardson wrote:

LGTM. Only concern might be that adding /usr/libexec to PATH adds too much stuff.

Hopefully I can get the strict tmppath usable by default soon so it shouldn't matter anymore then.

Yeah, so what I really wanted here with flua was some way to indicate that flua can/should be symlinked in from the host (preferably to the same location that I've added to BPATH) on the versions it's *not* being bootstrapped (__FreeBSD_version after I added it) to simplify this, since I don't really want to add /usr/libexec. Any advice on making that happen (or just getting flua into one of the standard BPATH/XPATH paths while leaving it installing to /usr/libexec) is quite welcome. =)

It should be possible to modify tools/build/Makefile and change the host-symlinks target to add a flua symlink if it exists on the host.
Something like (untested):

.if exists(/usr/libexec/flua)
    mkdir -p ${DESTDIR}/usr/libexec
    ln -sf /usr/libexec/flua ${DESTDIR}/usr/libexec/flua
.endif

[kevans]

In D22464#491447, @arichardson wrote:

In D22464#491412, @kevans wrote:

In D22464#491409, @arichardson wrote:

LGTM. Only concern might be that adding /usr/libexec to PATH adds too much stuff.

Hopefully I can get the strict tmppath usable by default soon so it shouldn't matter anymore then.

Yeah, so what I really wanted here with flua was some way to indicate that flua can/should be symlinked in from the host (preferably to the same location that I've added to BPATH) on the versions it's *not* being bootstrapped (__FreeBSD_version after I added it) to simplify this, since I don't really want to add /usr/libexec. Any advice on making that happen (or just getting flua into one of the standard BPATH/XPATH paths while leaving it installing to /usr/libexec) is quite welcome. =)

It should be possible to modify tools/build/Makefile and change the host-symlinks target to add a flua symlink if it exists on the host.
Something like (untested):

.if exists(/usr/libexec/flua)
    mkdir -p ${DESTDIR}/usr/libexec
    ln -sf /usr/libexec/flua ${DESTDIR}/usr/libexec/flua
.endif

Yeah, I like that, thanks! I think the mkdir -p can safely be omitted -- we create it in the installdirs target now in case it's bootstrapped, which should always be run prior to host-symlinks if I understand correctly. If we later determine flua needs to be bootstrapped, that just gets built+installed over the symlink, right?

[arichardson]

In D22464#491516, @kevans wrote:

In D22464#491447, @arichardson wrote:

In D22464#491412, @kevans wrote:

In D22464#491409, @arichardson wrote:

LGTM. Only concern might be that adding /usr/libexec to PATH adds too much stuff.

Hopefully I can get the strict tmppath usable by default soon so it shouldn't matter anymore then.

Yeah, so what I really wanted here with flua was some way to indicate that flua can/should be symlinked in from the host (preferably to the same location that I've added to BPATH) on the versions it's *not* being bootstrapped (__FreeBSD_version after I added it) to simplify this, since I don't really want to add /usr/libexec. Any advice on making that happen (or just getting flua into one of the standard BPATH/XPATH paths while leaving it installing to /usr/libexec) is quite welcome. =)

It should be possible to modify tools/build/Makefile and change the host-symlinks target to add a flua symlink if it exists on the host.
Something like (untested):

.if exists(/usr/libexec/flua)
    mkdir -p ${DESTDIR}/usr/libexec
    ln -sf /usr/libexec/flua ${DESTDIR}/usr/libexec/flua
.endif

Yeah, I like that, thanks! I think the mkdir -p can safely be omitted -- we create it in the installdirs target now in case it's bootstrapped, which should always be run prior to host-symlinks if I understand correctly. If we later determine flua needs to be bootstrapped, that just gets built+installed over the symlink, right?

Yes it will overwrite the link.