Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32417

Improving build system

Path csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From pozz <pozzugno@gmail.com>
Newsgroups comp.arch.embedded
Subject Improving build system
Date Tue, 13 May 2025 17:57:40 +0200
Organization A noiseless patient Spider
Lines 66
Message-ID <vvvq5j$1lml0$1@dont-email.me> (permalink)
MIME-Version 1.0
Content-Type text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding 7bit
Injection-Date Tue, 13 May 2025 17:57:40 +0200 (CEST)
Injection-Info dont-email.me; posting-host="3e489c109cfb5f105050ff0561079d39"; logging-data="1759904"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18DjYw8AyBLBZw9hoJQiNwakHVgg6Y+StI="
User-Agent Mozilla Thunderbird
Cancel-Lock sha1:AtjL99gWwhEKx/n6xRPF+W//pzc=
Content-Language it
Xref csiph.com comp.arch.embedded:32417

Show key headers only | View raw

As some of you remember, some weeks ago we had a discussion on the build 
system of an embedded project.  I declared I usually use the graphical 
IDE released by silicon manufacturer (in my case, Atmel Studio and 
MCUXpresso IDE) and some of you suggested to improve this build system 
using a command line tool, such as the universal make.  Better if used 
in Linux or Linux-based system, such as msys or WSL.

I also declared I had many issues fine tuning a cross-platform Makefile 
that works in Windows and Linux-like shells at the same time and some of 
you suggested to use only WSL or msys, not Windows CMD shell.

Recently I found some time to try again and I wrote a decent Makefile as 
a starting point.  Now the command make, launched in a msys/mingw32 
shell, is able to build my project, at least a specific build 
configuration, what I name "simulator".

My projects usually have multiple build configurations. A few for 
different models of the same device, such as LITE, NORMAL and FULL.
Moreover, I have at least two different targets: embedded and simulator. 
The embedded target is the normal product, usually running on a Cortex-M 
or AVR8 MCU. The simulator target runs directly on Windows. I use it 
very often, because I found it's much faster and simpler to build native 
binaries and debug such processes. Of course, building a simulator needs 
a different compilers, such as msys2/mingw32 or WSL/gcc.
I also have a DEBUG build configuration (target=embedded) useful for 
some debugging directly on the target (no watchdog, uart logging enabled 
and so on).

So I could have 7 different build configurations: LITE|NORMAL|FULL for 
EMBEDDED|SIMULATOR plus DEBUG.

I think it isn't difficult to change my Makefile to process commands of 
type:

    make CONFIG=LITE TARGET=embedded
    make CONFIG=FULL TARGET=simulator
    make CONFIG=DEBUG

There are many compiler options that are common to all builds (-Wall, 
-std=c99 and so on).  Some options are target specific (for example 
-DQUARTZ_FREQ_MHZ=16 -Isrc/ports/avr8 for embedded or 
-Isrc/ports/mingw32 for simulator).

I could generate the correct options by using ifeq() in Makefile.

How to choose the correct toolchain? Embedded target needs arm-gcc 
toolchain, for example in

   C:\Program Files 
(x86)\Atmel\Studio\7.0\toolchain\arm\arm-gnu-toolchain\bin

while simulator targets needs simply gcc.

How do you choose toolchain in Makefile?  I think one trick is using the 
prefix.  Usually arm-gcc is arm-none-eabi-gcc.exe, with "arm-none-eabi-" 
prefix.  Is there other approach?

I don't know if I could install arm-gcc in msys2 (I'm quite sure I can 
install it in WSL), but for legacy projects I need to use the Atmel 
Studio toolchain.  How to call Atmel Studio arm toolchain installed in

   C:\Program Files 
(x86)\Atmel\Studio\7.0\toolchain\arm\arm-gnu-toolchain\bin

from msys shell?  Should I change the PATH and use arm-none-eabi- prefix?

Back to comp.arch.embedded | Previous | Next — Next in thread | Find similar

Thread

Improving build system pozz <pozzugno@gmail.com> - 2025-05-13 17:57 +0200
  Re: Improving build system Nicolas Paul Colin de Glocester <Spamassassin@irrt.De> - 2025-05-13 22:48 +0200
  Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-14 11:03 +0200
    Re: Improving build system George Neuner <gneuner2@comcast.net> - 2025-05-14 15:21 -0400
      Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-15 09:48 +0200
      Re: Improving build system Nioclás Pól Caileán de Ghloucester <Spamassassin@irrt.De> - 2025-07-04 18:38 +0200
    Re: Improving build system pozz <pozzugno@gmail.com> - 2025-05-14 23:51 +0200
      Re: Improving build system Nicolas Paul Colin de Glocester <Spamassassin@irrt.De> - 2025-05-15 01:00 +0200
        Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-15 11:17 +0200
          Re: Improving build system Nicolas Paul Colin de Glocester <Spamassassin@irrt.De> - 2025-05-16 12:21 +0200
            Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-16 14:42 +0200
      Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-15 11:03 +0200
        Re: Improving build system pozz <pozzugno@gmail.com> - 2025-05-15 23:25 +0200
          Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-16 11:12 +0200
            Re: Improving build system pozz <pozzugno@gmail.com> - 2025-05-16 12:46 +0200
              Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-16 15:30 +0200
                Re: Improving build system pozz <pozzugno@gmail.com> - 2025-05-16 16:17 +0200
    Re: Improving build system pozz <pozzugno@gmail.com> - 2025-05-16 15:45 +0200
      Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-16 17:20 +0200
        Re: Improving build system pozz <pozzugno@gmail.com> - 2025-05-17 10:56 +0200
  Re: Improving build system Stefan Reuther <stefan.news@arcor.de> - 2025-05-14 18:06 +0200

csiph-web