Always add ${TARGET}.${TARGET_ARCH} to objtree path.

[emaste]

I think this change should be fine by itself, but isn't completely useful without follow-on work.

Should we mention this in UPDATING though? In some ways this is just an internal detail, but I've often had to go grovelling in here in the past, and it could confuse someone who has many native and cross-build subdirs in /usr/obj I think.

[imp]

In D3711#76679, @emaste wrote:

I think this change should be fine by itself, but isn't completely useful without follow-on work.

Should we mention this in UPDATING though? In some ways this is just an internal detail, but I've often had to go grovelling in here in the past, and it could confuse someone who has many native and cross-build subdirs in /usr/obj I think.

I think WORLDTMP likely needs a .${MACHINE_ARCH} added to the end (and no, we don't need ${MACHINE} here, though PC98 may not be completely pure, I think it's just extra files, none of which matters to the build.

But, if we do that, then installworld on $other-arch may fail... It shouldn't in theory, but when I've defined CROSS_BUILD_TEST in the past, there's been "issues" here.

[emaste]

LGTM if it works, along with an UPDATING entry.

[emaste]

Although I'd like to split out the target-agnostic build tools, and use a scheme like NetBSD's - e.g. ${MAKEOBJDIRPREFIX}/tooldir.FreeBSD-10.1-STABLE-amd64

[emaste]

I've been running with this in my staging tree for a while without trouble.

[emaste]

What's the next step here?

[bdrewery]

Personally I'd rather see something like /usr/obj/CURDIR/target.target_arch than /usr/obj/target.target_arch/CURDIR. It makes it simpler for cleanup of a build for 1 tree.

[bdrewery]

My idea may be harder without controlling .OBJDIR more. I am testing using MK_AUTO_OBJ with buildworld which would let us control .OBJDIR further. I'll experiment with using the path I suggested with my work and get back to you with results in a few days.

[emaste]

In D3711#128375, @bdrewery wrote:

My idea may be harder without controlling .OBJDIR more. I am testing using MK_AUTO_OBJ with buildworld which would let us control .OBJDIR further. I'll experiment with using the path I suggested with my work and get back to you with results in a few days.

Any update?

[bdrewery]

I'll have an update by this weekend about this.

[bdrewery]

Looking over the share/mk/local.meta.sys.mk, it does exactly what I think would be best here.

Building from /root/git/freebsd with a MAKEOBJDIRPREFIX of /usr/obj it comes up with object directories of:

/usr/obj/root/git/freebsd/${TARGET}.${TARGET_ARCH}/${RELDIR}

RELDIR is the directory being built in relative to the top, such as "bin/sh" or "usr.bin/clang". This allows us to always use TARGET.TARGET_ARCH (which I support) and allows more easily keeping related object directories organized in MAKEOBJDIRPREFIX.

I'm trying to adapt the behavior to Makefile.inc1. In that world I've had problems with getting rescue/rescue to build properly since it nests MAKEOBJDIRPREFIX within itself. I'll need to resolve that for my proposed change as well.

[emaste]

In D3711#136228, @bdrewery wrote:

/usr/obj/root/git/freebsd/${TARGET}.${TARGET_ARCH}/${RELDIR}

ok, that sounds fine to me

[bdrewery]

I'm going to move most of the OBJDIR handling logic out of the meta mode file and into a shared file that both buildworld and meta mode can share. It will be nice to get them using the same objdir. It will introduce a few new variables that can be used in the tree such as OBJROOT and OBJTOP. OBJROOT being the /usr/obj/usr/src dir and OBJTOP being /usr/obj/usr/src/amd64.amd64 dir.

[emaste]

Is this still in progress?

[emaste]

Ping?

[bdrewery]

D12840 obsoletes this change.