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: Re: Improving build system
Date: Fri, 16 May 2025 15:45:04 +0200
Organization: A noiseless patient Spider
Lines: 119
Message-ID: <1007fgv$3kivm$2@dont-email.me>
References: <vvvq5j$1lml0$1@dont-email.me> <1001m9t$2drv1$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 16 May 2025 15:45:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b1ab8f7032ac741dfc92317180d6ca90"; logging-data="3820534"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19zw1y4uyaS4RlqA0jRCu2XgeWuTYgly2c="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:y2IG9o/S59qmnS5C+SsWh7eajEA=
Content-Language: it
In-Reply-To: <1001m9t$2drv1$1@dont-email.me>
Xref: csiph.com comp.arch.embedded:32433

Il 14/05/2025 11:03, David Brown ha scritto:
> On 13/05/2025 17:57, pozz wrote:
[...]
> 3.
> 
> Makefiles can be split up.  Use "include" - and remember that you can do 
> so using macros.  In my makefile setups, I have a file "host.mk" that is 
> used to identify the build host, then pull in a file that is specific to 
> the host:
> 
> # This is is for identifying host computer to get the paths right
> 
> ifeq ($(OS),Windows_NT)
>    # We are on a Windows machine
>    host_os := windows
>    host := $(COMPUTERNAME)
> else
>    # Linux machine
>    host_os := linux
>    host := $(shell hostname)
> endif
> 
> ifeq "$(call file-exists,makes/host_$(host).mk)" "1"
>    include makes/host_$(host).mk
> else
>    $(error No host makefile host_$(host).mk found)
> endif
> 
> Then I have files like "host_xxx.mk" for a computer named "xxx", 
> containing things like :
> 
> toolchain_path := /opt/gcc-arm-none-eabi-10-2020-q4-major/bin/
> 
> or
> 
> toolchain_path := c:/micros/gcc-arm-none-eabi-10_2020-q4-major/bin/
> 
> 
> All paths to compilers and other build-related programs are specified in 
> these files.  The only things that are taken from the OS path are 
> standard and common programs that do not affect the resulting binary files.

Regarding this point, I tried to set

    toolchain_path := c:\\msys64\\mingw64\\bin

but it doesn't work (a popup error is shown about libwinpthread-1.dll). 
Even if I call gcc directly from CMD doesn't work for the same reason.

I found the problem disappears if I set the toolchain path in the 
PATH... but, hey, we were going to put the toolchain path in the 
makefile to avoid setting the PATH on the command line, but it seems 
impossible!





> Then I have a "commands.mk" file with things like :
> 
> ATDEP := @
> 
> toolchain_prefix := arm-none-eabi-
> 
> CCDEP := $(ATDEP)$(toolchain_path)$(toolchain_prefix)gcc
> CC := $(AT)$(CCACHE) $(toolchain_path)$(toolchain_prefix)gcc
> LD := $(AT)$(toolchain_path)$(toolchain_prefix)gcc
> OBJCOPY := $(AT)$(CCACHE) $(toolchain_path)$(toolchain_prefix)objcopy
> OBJDUMP := $(AT)$(CCACHE) $(toolchain_path)$(toolchain_prefix)dump
> SIZE := $(AT)$(CCACHE) $(toolchain_path)$(toolchain_prefix)size
> 
> 
> Put CONFIG dependent stuff in "config_full.mk" and similar files.  Put 
> TARGET specific stuff in "target_simulator.mk".  And so on.  It makes it 
> much easier to keep track of things, and you only need a few high-level 
> "ifeq".
> 
> 
> Keep your various makefiles in a separate directory.  Your project 
> makefile is then clear and simple - much of it will be comments about 
> usage (parameters like CONFIG).
> 
> 
> 4.
> 
> Generate dependency files, using the same compiler and the same include 
> flags and -D flags as you have for the normal compilation, but with 
> flags like -MM -MP -MT and -MF to make .d dependency files.  Include 
> them all in the makefile, using "-include" so that your makefile does 
> not stop before they are generated.
> 
> 
> 5.
> 
> Keep your build directories neat, separate from all source directories, 
> and mirroring the tree structure of the source files.  So if you have a 
> file "src/gui/main_window.c", and you are building with CONFIG=FULL 
> TARGET=embedded, the object file generated should go in something akin 
> to "builds/FULL/embedded/obj/src/gui/main_window.o".  I like to have 
> separate parts for obj (.o files), dep (.d files), and bin (linked 
> binaries, map files, etc.).  You could also mix .d and .o files in the 
> same directory if you prefer.
> 
> This means you can happily do incremental builds for all your 
> configurations and targets, and don't risk mixing object files from 
> different setups.
> 
> 
> 6.
> 
> Learn to use submakes.  When you use plain "make" (or, more 
> realistically, "make -j") to build multiple configurations, have each 
> configuration spawned off in a separate submake.  Then you don't need to 
> track multiple copies of your "TARGET" macro in the same build - each 
> submake has just one target, and one config.
> 
> 
>