Is the following as intended?
In /usr/src/Makefile.inc1 there is:
# If all targets are disabled for system llvm then don't expect it to work
# for cross-builds.
.if !defined(TOOLS_PREFIX) && ${MK_LLVM_TARGET_ALL} == "no" && \
${MACHINE} != ${TARGET} && ${MACHINE_ARCH} != ${TARGET_ARCH} && \
!make(showconfig)
MK_SYSTEM_COMPILER= no
MK_SYSTEM_LINKER= no
.endif
Take an example context of:
MACHINE=arm64 TARGET=arm
MACHINE_ARCH=aarch64 TARGET_ARCH=armv7
This would potentially allow the MK_SYSTEM_COMPILER
and MK_SYSTEM_LINKER assignments to "no".
(As an example use: MK_SYSTEM_COMPILER=="yes" is
required to set to disable the bootstrap compiler
via MK_CLANG_BOOTSTRAP and MK_GCC_BOOTSTRAP being
set to "no".)
Note: Any time ${MACHINE} != ${TARGET} then
${MACHINE_ARCH} != ${TARGET_ARCH} for the
existing/supported combinations (if I understand
right). This is probably a requirement on any
future combinations as well in order to avoid
_ARCH's being ambiguous.
But both the contrasting example contexts of:
MACHINE=arm TARGET=arm
MACHINE_ARCH=armv6 TARGET_ARCH=armv7
and:
MACHINE=arm TARGET=arm
MACHINE_ARCH=armv7 TARGET_ARCH=armv7
would prevent the MK_SYSTEM_COMPILER and
MK_SYSTEM_LINKER assignments to "no" based
on (at least) ${MACHINE} == ${TARGET}.
Note: Any time ${MACHINE_ARCH} == ${TARGET_ARCH}
then ${MACHINE} == ${TARGET} for the
existing/supported combinations (if I understand
right). This is probably a requirement on any
future combinations as well in order to avoid
_ARCH's being ambiguous.
So overall it seems the code is effectively (for
valid combinations):
.if !defined(TOOLS_PREFIX) && ${MK_LLVM_TARGET_ALL} == "no" && \
${MACHINE} != ${TARGET} && \
!make(showconfig)
MK_SYSTEM_COMPILER= no
MK_SYSTEM_LINKER= no
.endif
Is that the intent?
(I avoided powerpc combinations because of the
current problematical status of clang/llvm materials
when powerpc family members are involved for
FreeBSD. Hopefully some year this will have proved
temporary.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
