This is the default value for ${MACHINE} on Linux and Mac and changing it
to amd64 is required in order to build FreeBSD on those systems.
Details
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 14737 Build 14858: arc lint + arc unit
Event Timeline
Makefile | ||
---|---|---|
310–315 | This shouldn't be needed with the share/mk/src.sys.env.mk changes since MACHINE will already be amd64 by the time this file is parsed. | |
include/Makefile | ||
396–401 | Testing this piece is weird because it's part of a totally different build system. I think your change and the two HOST_MACHINE[_ARCH] lines are not needed if you just fixup the arch in share/mk/host-target.mk. We'll definitey want @sjg signoff on touching that file though. | |
share/mk/src.sys.env.mk | ||
57 | A comment that this is for cross-os builds would help not cause this to be trimmed by accident. |
Makefile.inc1 | ||
---|---|---|
450–453 | Is all this to prevent requiring TARGET_ARCH? |
Also why have:
BUILD_ARCH!= uname -p
<hack BUILD_ARCH>
and also
HOST_MACHINE_ARCH!= uname -p
<hack HOST_MACHINE_ARCH>
why not have them both be
FOO!= tools/build/build_machine
FOO_ARCH!=toos/build/build_machine_arch
and put all the hacks there. amd64 isn't the only mismatch.
Makefile | ||
---|---|---|
313 | quotes are incorrect here | |
include/Makefile | ||
396–401 | Yes, this looks questionable.... and there should be no need to touch host-target.mk There should be a very clear distinction between the "host" and the "target" In our build (Junos and FreeBSD) we use the pseudo MACHINE "host" to trigger building for the host and its objdir is named with the value of ${HOST_TARGET} eg. freebsd11-amd64 or linux3-x86_64 |
Right, I know I made this suggestion, but I'm still struggling to understand why we need it. That's not been articulated very well, so it's hard to comment on its suitability for the problem it's supposed to solve.
! In D14166#297774, @imp wrote:
Right, I know I made this suggestion, but I'm still struggling to understand why we need it. That's not been articulated very well, so it's hard to comment on its suitability for the problem it's supposed to solve.
So the problem is that lots of makefiles do stuff like .if exists(${MACHINE_ARCH}/foo) and without these changes I got build errors. It is probably only an issue during the bootstrap-tools, build-tools and cross-tools stages since I think after that TARGET_ARCH is used.
MACHINE_ARCH is set at the top level from TARGET_ARCH, which you should always be setting when building on a foreign OS. Or did you want to implement the default build of 'whatever is closest to the foreign OS's arch on FreeBSD'? So I'm having heartburn with the notion that we'd pollute ares of our build to enable this feature since I'm having trouble understanding its value. If so, the list of translations is also woefully incomplete as mips, arm and I think powerpc use different naming conventions as well. It would be better to say 'You must define TARGET_ARCH' on a foreign OS, I think, but I'm open to a better understanding that would change my mind on this point. I also have trouble understanding how it would make it past the 'this is the valid list of machine/machine_arch combinations we have' as well for the downstream makefiles to be an issue.
I think we should require TARGET and TARGET_ARCH for cross-os builds. However, I believe the values for MACHINE/MACHINE_ARCH are wrong when make is invoked as ${BMAKE} or ${TMAKE}: i.e. during legacy, build-tools, bootstrap-tools, cross-tools, kernel-tools. I can't remember which programs were failing because of this, I will try again and report back.
Looking at the code, I suspect you may be right... We use it not only for setting MACHINE in the WMAKE and IMAKE phases, but the host's MACHINE* is also implicitly used earlier for the BMAKE and TMAKE phases. We don't set MACHINE* there, so rely on the host's notion, which would lead to the problems you are reporting. Please let me know what your tests say, but I suspect it's more for 'tricking FreeBSD to run on the right host type' rather than just to make the default TARGET be right, in which case it may not be able to be helped...
I just managed to build FreeBSD on MacOS without these changes so it seems like my later changes to libegacy have made this mostly unncessary.
I believe the changes to include/Makefile and the toplevel Makefile for native-xtools are still required but I'm not sure how important it is to have these targets working on other operating systems.