Page MenuHomeFreeBSD

Don't consider ccache to be an external compiler.
AbandonedPublic

Authored by bdrewery on Aug 25 2015, 11:56 PM.

Details

Reviewers
brooks
bapt
imp
Summary

When using the recommended CC=/usr/local/libexec/ccache/world/cc, the logic
here was considering ccache to be an external compiler and skipping building
the internal compiler. This leads to problems where the internal compiler
has flags that the source files depend on that the host compiler does not
understand.

This is currently relevant building 10+ on a host that is <10
using ccache as the build tries to use the host /usr/bin/cc (gcc) with clang
flags such as -Qunused-arguments.

Sponsored by EMC

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 236
Build 236: arc lint + arc unit

Event Timeline

bdrewery retitled this revision from to Don't consider ccache to be an external compiler..
bdrewery updated this object.
bdrewery edited the test plan for this revision. (Show Details)
bdrewery added reviewers: imp, brooks, bapt.

I am open to better solutions on this. We ran into it at Isilon due to adding compiler flags that our build systems didn't understand.

Here's my two cents.... Not sure it is an improvement...

Makefile.inc1
366

I've never liked this test at all. I like it even less that you're expanding it. This suggests, though doesn't require, we'd better off with some MK_xxxxx test with some default setting in src.conf.mk. But this is a fairly specialized case...

440

Same here.

1515

Again with the same thing... It would be better MK_CROSS_COMPILER test in the other two places?

I agree with @imp that these tests should not be expanded this way. If nothing else, there is no reason to believe that ccache is using the internal compiler.

Makefile.inc1
366

I have no opinion on how to support external toolchains. I just want ccache to be fixed. This finalizes the ccache+world+"clang" issues.

If we want to make an external toolchain explicit rather than the current implicit check I am all for that.

How about a MK_EXTERNAL_COMPILER who's default depends on XCC? That would preserve the current behavior while making it overridable. The only problem then is that setting WITH_EXTERNAL_COMPILER without setting XCC is likely to break.

In D3484#71443, @brooks wrote:

How about a MK_EXTERNAL_COMPILER who's default depends on XCC? That would preserve the current behavior while making it overridable. The only problem then is that setting WITH_EXTERNAL_COMPILER without setting XCC is likely to break.

I'm good with that. You can add a seat-belt for safety if you want. I'm ambivalent about that detail.

I'm going for something more ports-like now and will submit that for review.