mr_georg
mr_georg

Reputation: 3713

Using two tool-chains with cmake

For cross-compiling projects for a microcontroller (msp430 from TI), I use the clang++ and the mspgcc from TI. Basically the compile process is as follows:

file.cpp 
--(llvm clang++)--> file.ll 
--(llvm llc)--> file.s 
--(ti msp430-elf-gcc)--> file.o 
--(ti msp430-elf-gcc)--> a.out (executable)

What I want to do, is compile my projects with cmake. I have read about the toolchain option for cmake (e.g. https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html?highlight=toolchain), but it does not quite fit my situation.

Any possibilities to achieve it?


The exact steps for compiling are:

/usr/local/opt/llvm/bin/clang++ -I ~/ti/gcc/include/ -I ~/ti/gcc/msp430-elf/include/ -D__MSP430F5529__ -S -emit-llvm -std=c++11 --target=msp430 -Wall -c file.cpp -o file.ll

/usr/local/opt/llvm/bin/llc -march=msp430 file.ll -o file.s

~/ti/gcc/bin/msp430-elf-gcc -Wall -D_GNU_ASSEMBLER_ -I ~/ti/gcc/include/ -mmcu=msp430f5529 -mcpu=430 -x assembler -Wa,-gstabs -c file.s -o file.o

~/ti/gcc/bin/msp430-elf-gcc -mmcu=msp430f5529 -B ~/ti/gcc/include/ -mcpu=430 -Wl,-Map=a.out.map file.o  -o a.out 

Upvotes: 0

Views: 867

Answers (1)

Chintalagiri Shashank
Chintalagiri Shashank

Reputation: 990

For a start, though admittedly suboptimal, you could treat one of the compile commands as simply a custom command.

Note that this approach will give you little more than a regular old shell script with a lot of added on syntactical headaches for the step you use it for.

From the commands you've listed, it looks like you're only using msp430-elf-gcc for converting an otherwise fully integrated assembly listing into msp430 hex. If that is the case, I'd set up the toolchain to handle clang++ and all the dependency resolution that goes with compiling serious programs. The later msp430-elf-gcc command can simply be listed as a custom command which includes the target of your clang++ build as a dependency. In fact, all of the last three steps you have are fairly straightforward in that regard and may well be amenable to being essentially hardcoded.See this SO answer.

A slightly cleaner approach, though you might have to put in some effort to make sure it's sufficient or not, would be to link the custom_command to the target. Meta-code from a cursory reading of the add_custom_command docs :

add_executable(file.ll ${SOURCES})
add_custom_command(TARGET file.ll
                   POST_BUILD
                   COMMAND llc [ARGS] [args1...]
                   COMMAND msp430-elf-gcc [ARGS] [args2...] 
                   COMMAND msp430-elf-gcc [ARGS] [args3...] 
                   [WORKING_DIRECTORY dir]
                   [COMMENT comment] [VERBATIM])

My initial impression is that add_custom_command with the OUTPUT based signature (as opposed to the TARGET based signature) may prove to be more intuitive, but that would depend on your personal preferences as well as the overall complexity of your build.

Ideally, you'd have to set up a more complicated build using either ExternalProject or running cmake twice with different CMakeLists. I've never had to do either badly enough to figure out how that works, though.

Upvotes: 2

Related Questions