Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Makefile.inc1 | ||
---|---|---|
3335 | removing ${_gcc} is needed anyway; what do you suggest we do w/ XDEV if MK_CLANG==no? |
Makefile.inc1 | ||
---|---|---|
3335 | It makes no sense. It should fail in some way. Xdev is there to make the compiler and toolchain stuff. It was only a variable here since clang was introduced. It used to be unconditional gcc. |
Makefile.inc1 | ||
---|---|---|
3335 | This issue predates my proposed change though; archs without either clang or gcc 4.2.1 (like riscv) would have had this problem already. |
Makefile.inc1 | ||
---|---|---|
3335 | It's ok, I guess. It only makes sense for in tree toolchain... we can leave it likes this... |
Makefile.inc1 | ||
---|---|---|
3335 | I think we could/should still do something about it, but it can happen before or after this change. Probably if any of ${_clang_libs}, ${_lld}, ${_binutils}, ${_elftctools}, ${_clang} are empty it could be a .error. Well, empty ${_binutils} is OK depending on arch. |
Makefile.inc1 | ||
---|---|---|
180–181 | We should probably rm the bits to try to set CROSS_BINUTILS_PREFIX. aarch64 and riscv64 were the users of this before and they both now use LLD. I think it won't conflict. I'll see if I can do that as a separate change sooner. One thing we want to make sure of today is that right now 'make buildworld' for mips and sparc64 should be failing unless someone has manually set WITH_GCC to yes. Not sure where that needs to happen (either here or src.opts.mk) |
We should probably rm the bits to try to set CROSS_BINUTILS_PREFIX. aarch64 and riscv64 were the users of this before and they both now use LLD. I think it won't conflict. I'll see if I can do that as a separate change sooner.
I don't think it will conflict, and in any case I'll rebase this over the change if it goes in first.
So one question I have is if 'make xdev' makes sense in a clang world? clang is already a cross-compiler via -target. Probably not for this change, but if 'make xdev' is now obsolete it might be nice to GC those bits as a followup.
tools/build/mk/OptionalObsoleteFiles.inc | ||
---|---|---|
1766–1767 | I think it is simplest if we just move it all. |
It's used in package building. There, cc needs to generate the target's binaries w/o a lot of ability to intercept. We'd have to rework that stuff to be a series of shell scripts to be a drop in. This is in the context of the arm jail on a amd64 host. We drop the amd64 binaries into that for better performance. so definitely not for this change.
No, I'm confused. That being said, we almost certainly want to move this be something we do in ports and I'm a bit concerned that it's going to be hard to make this model work with riscv (where someone decided the triple should encode nearly nothing about the ABI.)
I suspect that it will become something that generates the cc, et al, shell scripts that call clang with the right args, which may be more than just --target triple, if need be. I suspect that will answer this concern. At the moment, clang built this will works, at least for arm and mips. After the change, xdevbuild will creaete the shell scripts and xdevinstall will arrange things such that they can be run in the chroot jail we use to build packages.
And to be clear, this is cross-building packages only, not 100% native on native hardware.
- rebase
- remove gperf remnants
- remove cc_tools leftovers from Makefile.inc1
- # Clean out improper TARGET=MACHINE files - ${_+_}cd ${.CURDIR}/gnu/usr.bin/cc/cc_tools; ${NXBTMAKE} cleandir
Makefile.inc1 | ||
---|---|---|
223–224 | I think this case can't even happen anymore since you just removed the WANT_COMPILER_TYPE=gcc above? That is, I think you can just remove the .elif and not bother adding this .error. |
Makefile.inc1 | ||
---|---|---|
223–224 | Good point, fixed locally and will be included in next upload. |
I like it, and agree with the other comments you've already said you'd address.
Makefile.inc1 | ||
---|---|---|
2691 | as others have noted, we should revisit what we want to do with xtools/xdev targets once we have gcc out of the tree since clang may be able to do a lot of the heavy lifting more easily. Though it's complicated by the fact that we build libraries and such too... | |
3335 | I'd suggest having the whole 'rototil xdev' stuff be separate from this change. | |
share/mk/src.opts.mk | ||
308 | ah, gdb... | |
480 | This will cause a merge conflict before the end of the month... |
share/mk/src.opts.mk | ||
---|---|---|
480 | A rather trivial one though :) |
ObsoleteFiles.inc | ||
---|---|---|
40 | Looks good to me, thanks |