cortexm: Add support for building with LLVM/Clang

[jnohlgard]

as an alternative to the default GCC toolchain.

export BUILD_WITH_CLANG=1
export CC=clang

export TOOLCHAIN=llvm

or

export TOOLCHAIN=clang

to build with Clang instead of GCC

[jnohlgard]

as for -fshort-enums:
newlib nano on my machine seems to be built with -fshort-enums which causes warnings during linking with RIOT built using Clang. It seems like gcc defaults to using short enums and clang defaults to using word size enums because RIOT files built with GCC do not cause any warnings.

[jnohlgard]

is BUILD_WITH_CLANG a suitable environment variable name or is it too long?

[haukepetersen]

I would opt for changing the switches name to something more general, maybe to TOOLCHAIN. Then you coult build with

TOOLCHAIN=gnu make all

or

TOOLCHAIN=llvm make all

or anything else that might come up.

So in the Makefile you could just write:

#default to GNU
TOOLCHAIN ?= gnu
...

include $(RIOTBOARD)/Makefile.include.$(TOOLCHAIN)

how does that sound?

[jnohlgard]

Good idea, I will adapt this pr when I am back at the computer.
On May 30, 2015 3:32 PM, "Hauke Petersen" notifications@github.com wrote:

I would opt for changing the switches name to something more general,
maybe to TOOLCHAIN. Then you coult build with

TOOLCHAIN=gnu make all

or

TOOLCHAIN=llvm

or anything else that might come up.

So in the Makefile you could just write:

#default to GNU
TOOLCHAIN ?= gnu
...

include $(RIOTBOARD)/Makefile.include.$(TOOLCHAIN)

how does that sound?

—
Reply to this email directly or view it on GitHub
#3119 (comment).

[LudwigKnuepfer]

Personally, I would prefer to set this based on the value of CC. I.e. when I want to build using llvm, I usually just export CC=clang and be done with it.

[jnohlgard]

@LudwigOrtmann @haukepetersen OK, how about this:
Let TOOLCHAIN be the primary definition, but if TOOLCHAIN is unset or empty, then look at the CC variable and try to deduce the TOOLCHAIN variable from the name there?

[jnohlgard]

(and lastly go with the platform default, i.e. gnu for cortex)

[LudwigKnuepfer]

Is there any advantage in having TOOLCHAIN in addition to CC? Or vice versa - do you see any problems in using CC only?

[jnohlgard]

@LudwigOrtmann TOOLCHAIN is the more logical name since this affects the entire chain, including compiling C, C++, assembler, linking, objcopy (though llvm doesn't have a proper replacement for that one yet)

Also it is useful inside make to have a variable to check use in ifeq statements for specific compiler options without having to strip the PREFIX etc from it, so there will be a use for a TOOLCHAIN variable inside the build system, might as well let people override it from the environment/command line.

[jnohlgard]

rebased, updated with TOOLCHAIN/CC

[jnohlgard]

Added short description to https://github.com/RIOT-OS/RIOT/wiki/Build-Flags I will edit according to the final state of this PR when merged.

[haukepetersen]

if this line is dependent on the toolchain, I am wondering if it would make it easier, to move this line to Makefile.include.gnu and Makefile.include.llvm...

[jnohlgard]

If we move it, I think it will be easily overlooked that there are two places to modify if we need to change any flags. Also, it makes reading the files more tedious (switching back and forth between two/three files in the editor)

[kaspar030]

Also, we should keep cortex stuff out of Makefile.common.gnu/llvm, as the latter might be reused for non-cortex cpus.

[haukepetersen]

By looking at the Makefile now, I am not sure if I am a big fan of deducting the TOOLCHAIN from CC. It does not make the Makefile more readable while adding in my opinion not really much additional benefit. So I would actually vote for using the TOOLCHAIN variable only for selecting the correct toolchain specific sub-Makfile. The CC option can still be used for selecting the compiler, but only the compiler and that is what this option is for in the first place!

[jnohlgard]

@haukepetersen the way the board makefiles are written the CC variable can't actually be used for selecting the compiler since it is always overridden in the toolchain makefiles (both before and after this PR)

[jnohlgard]

@haukepetersen I do agree though that the CC checking block is making the file a bit more complex without adding much of a feature. All that is needed is export TOOLCHAIN=llvm instead of CC=clang

I also added export TOOLCHAIN=clang as an alias because it would be logical for users to believe that the toolchain would be called clang when the compiler command is clang.

[jnohlgard]

@LudwigOrtmann what is your opinion on this?
Are you OK with removing the big ifeq [CC] block from the Makefile?

[LudwigKnuepfer]

@gebart yes

[jnohlgard]

rebased, removed the CC checks and squashed the previous commits. OK to squash all?

[kaspar030]

TOOLCHAIN ?= gnu saves some lines here.

[kaspar030]

Just a thought: many build systems use TOOLCHAIN for the actual triple prefix (e.g., arm-none-eabi-). But I can't think of a better name. Opinions?

[jnohlgard]

I can't think of a better name either, and I have not seen the TOOLCHAIN=arch-prefix- usage yet. Is it widespread?

[kaspar030]

The ?= and ifeq above are redundant, right?

[jnohlgard]

yes, addressed.

[kaspar030]

OK to squash all?

Yeah, lets merge and improve later.

[jnohlgard]

Addressed some comments.

• Move newlib include search to sys/newlib/Makefile.include
• Add override for TOOLCHAIN=clang to force TOOLCHAIN=llvm
• small comment/whitespace fixes.

[jnohlgard]

I am happy with the current state now. OK to squash again?

[kaspar030]

yes!

[jnohlgard]

rebased, squashed, ready

[jnohlgard]

Travis is green, any ACKs?

[haukepetersen]

ACK and go.