On 10/17/2015 10:11 AM, Bryan Drewery wrote: > On 10/17/2015 9:00 AM, Bryan Drewery wrote: >> On 10/17/2015 8:57 AM, Bryan Drewery wrote: >>>> Guess what happens when I use a proper clang-tblgen? >>>> >>>> $ make all >>>> /usr/obj/home/ngie/git/freebsd/src/usr.bin/clang/clang-tblgen/clang-tblgen >>>> -gen-arm-neon -d arm_neon.d -o arm_neon.h >>>> /home/ngie/git/freebsd/src/lib/clang/include/../../../contrib/llvm/tools/clang/include/clang/Basic/arm_neon.td >>>> $ >>>> >>>> Voila. >>>> >>>> So this is happening because it’s using clang-tblgen from the build host >>>> somehow, which is not able to process the .td files. >>> Perhaps PATH got set wrong somehow. Note that the build log does not >>> have an absolute path for clang-tblgen, as the above code would cause. >>> It is just using the default PATH as other builds do. >> >> I reproduced this PATH issue here locally and digging deeper. >> > > Yes, something in my changes definitely is passing the wrong PATH here. >
I figured it out. I've been working on cleaning up bsd.subdir.mk for usage with 'includes' because it currently uses a hack that runs sub-makes itself for 'buildincludes' and 'installincludes' (see r289282 which was reverted but I have a working version now). The older, duplicated bsd.subdir.mk logic, for calling 'includes' was being executed in each subdir directly, meaning 'cd lib && make includes' became 'cd lib && make buildincludes && make installincludes'. Now that the bsd.subdir.mk logic is used it is doing 'make includes', which becomes 'make buildincludes && make installincludes' from the top-level which pulls in the PATH=<default path> from /Makefile. This of course impacts all of the targets I changed. I'll have a fix committed shortly. -- Regards, Bryan Drewery
signature.asc
Description: OpenPGP digital signature
