Use default CLANG build options for little-endian ARM

[emaste]

Summary

We previously disabled CLANG_FULL because it couldn't be built by the in-tree GCC. As of Clang 3.5 we cannot build any of the in-tree Clang with in-tree GCC, so there's no longer a reason to disable CLANG_FULL.

[dim]

This is fine with me, but are there really no situations where this could make e.g. upgrading, or building from another branch more difficult? (Though OTOH people can always manually specify WITHOUT_CLANG_FULL...)

[emaste]

In D2525#46594, @dim wrote:

This is fine with me, but are there really no situations where this could make e.g. upgrading, or building from another branch more difficult? (Though OTOH people can always manually specify WITHOUT_CLANG_FULL...)

Hmm. This was introduced relatively recently (review D1294), but I'm a bit unsure based on the comment there.

CLANG_FULL enables:

.if ${MK_CLANG_FULL} != "no"
CFLAGS+=        -DCLANG_ENABLE_ARCMT \
                -DCLANG_ENABLE_STATIC_ANALYZER
.endif # MK_CLANG_FULL

and

.if ${MK_CLANG_FULL} != "no"
_clangstaticanalyzer= \
        clangstaticanalyzerfrontend \
        clangstaticanalyzercheckers \
        clangstaticanalyzercore
_clangarcmigrate= \
        clangarcmigrate
.endif # MK_CLANG_FULL

but in-tree gcc is incapable of building any of clang 3.5.0+. Maybe the comment applied to a GCC port version?

In any case, I think there are very few users of FreeBSD/armbe, and they are certainly cross-compiling, probably from 10.1 or later.

[• ian]

What does CLANG_FULL get us that we don't have now?

How much time will this add to a native build? To a cross-build?

How many people will actually use the extra stuff this generates?

What I'm after here is the pain vs reward ratio for doing this. If it adds significant time to a build to get features that only a few developers and no end-users will find valuable, maybe we should just leave it as a thing the power users enable.

[emaste]

In D2525#46832, @ian wrote:

What does CLANG_FULL get us that we don't have now?

It adds the static analyzers and clangarcmigrate.

My point in this change is that these were disabled on LE arm due to build issues which no longer apply. If these are generally not of interest in "embedded" contexts we should have some sort of embedded knob, not per-arch defaults scattered about.

[emaste]

Rebase after rS284274 which switched ARMEB to Clang

[dim]

Let's just remove the complicated logic now. If somebody really needs to bootstrap the tree using gcc, they can always set WITHOUT_CLANG_FULL manually.