| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 28 |
| Nodes: | 6 (1 / 5) |
| Uptime: | 45:10:42 |
| Calls: | 422 |
| Calls today: | 1 |
| Files: | 1,024 |
| Messages: | 90,304 |
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?
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?
1.
Windows path naming is insane. Fortunately, you can almost always
override it. Whenever you install any serious program in Windows,
especially if you ever want to refer to it from the command line, batch >files, makefiles, etc., avoid names with spaces or "awkward" characters.
I recommend making top-level directories like "progs" or "compilers"
and putting the tools in there as appropriate. This also makes it
vastly easier to copy tools to other machines. And since you should
never upgrade your toolchains - merely add new versions to your
collection, in separate directories - it is easier if they are better >organised.
2.
You don't need to use bash or other *nix shells for makefile or other
tools if you don't want to. When I do builds on Windows, I run "make"
from a normal command line (or from an editor / IDE). It is helpful to
have msys2's usr/bin on your path so that make can use *nix command-line >utilities like cp, mv, sed, etc. But if you want to make a minimal
build system, you don't need a full msys2 installation - you only need
the utilities you want to use, and they can be copied directly (unlike
with Cygwin or WSL).
Of course you /can/ use fuller shells if you want. But don't make your >makefiles depend on that, as it will be harder to use them from IDEs, >editors, or any other automation.
On Wed, 14 May 2025 11:03:56 +0200, David Brown
<david.brown@hesbynett.no> wrote:
1.
Windows path naming is insane. Fortunately, you can almost always
override it. Whenever you install any serious program in Windows,
especially if you ever want to refer to it from the command line, batch
files, makefiles, etc., avoid names with spaces or "awkward" characters.
I recommend making top-level directories like "progs" or "compilers"
and putting the tools in there as appropriate. This also makes it
vastly easier to copy tools to other machines. And since you should
never upgrade your toolchains - merely add new versions to your
collection, in separate directories - it is easier if they are better
organised.
Just note that NTFS *does* have a limit on the number of entries in
the root directory of the drive. Offhand, I don't recall what is the
limit [for some reason 127 is stuck in my head] but note that the
typical Windows installation has only about ~20 folders in C:\.
Subdirectories, however, effectively are unlimited.
A handful of extra folders in the drive root certainly will not cause
any problem, but just don't try to install lots of software to
separate folders directly under the drive root.
2.
You don't need to use bash or other *nix shells for makefile or other
tools if you don't want to. When I do builds on Windows, I run "make" >>from a normal command line (or from an editor / IDE). It is helpful to
have msys2's usr/bin on your path so that make can use *nix command-line
utilities like cp, mv, sed, etc. But if you want to make a minimal
build system, you don't need a full msys2 installation - you only need
the utilities you want to use, and they can be copied directly (unlike
with Cygwin or WSL).
A number of common Unix utilities are available as native Windows executables, so a POSIX environment like msys2 or mingw is not even
needed [unless you want it for some other purpose, 8-) ].
https://sourceforge.net/projects/unxutils/
Of course you /can/ use fuller shells if you want. But don't make your
makefiles depend on that, as it will be harder to use them from IDEs,
editors, or any other automation.
Also note that, on Windows, Powershell is able to launch programs much
faster than CMD. [I don't know why, just that it does.]
Il 14/05/2025 11:03, David Brown ha scritto:
On 13/05/2025 17:57, pozz wrote:[...]
You are asking a lot of questions here. They are good questions, but
it would be a very long post if I tried to answer them all fully. So
instead, I will try to give a few hints and suggestions that you can
take further. I'll put numbers on them in case you want to reference
them in replies.
Ok, thank you very much for your time.
1.
Windows path naming is insane. Fortunately, you can almost always
override it. Whenever you install any serious program in Windows,
especially if you ever want to refer to it from the command line,
batch files, makefiles, etc., avoid names with spaces or "awkward"
characters. I recommend making top-level directories like "progs" or
"compilers" and putting the tools in there as appropriate. This also
makes it vastly easier to copy tools to other machines. And since you
should never upgrade your toolchains - merely add new versions to your
collection, in separate directories - it is easier if they are better
organised.
I know, but not all software installers work well if you change their
default installation path. When it comes to stupid and big IDEs (such
as Atmel/Microchip Studio), I prefer to avoid changing the default installation path (C:\Program Files (x86)\Atmel...) to avoid other
obscure issues.
It is already a miracle if that software runs without problems with the default installation path. I don't want to imagine what happens if I changed it.
Anyway until now I didn't find issues with spaces. Even in msys2 shell
I can use "/c/Program\ Files\ (x86)/...".
The other IDE I use is MCUXpresso. It is Eclipse based so I installed
it in c:\ without any temptations.
2.
You don't need to use bash or other *nix shells for makefile or other
tools if you don't want to. When I do builds on Windows, I run "make"
from a normal command line (or from an editor / IDE). It is helpful
to have msys2's usr/bin on your path so that make can use *nix
command-line utilities like cp, mv, sed, etc. But if you want to make
a minimal build system, you don't need a full msys2 installation - you
only need the utilities you want to use, and they can be copied
directly (unlike with Cygwin or WSL).
Of course you /can/ use fuller shells if you want. But don't make
your makefiles depend on that, as it will be harder to use them from
IDEs, editors, or any other automation.
In the beginning (some years ago) I started installing GNU Make for
Windows, putting it in c:\tools\make. Then I created a simple Makefile
and tried to process it on a standard Windows command line. It was a mess! I remember there were many issues regarding: slash/backslash on
file paths, lack of Unix commands (rm, mv, ...) and so on. Native
Windows tools need backslash in the paths, but some unix tools need
slash. It was a mess to transform the paths between the two forms.
After this attempt, I gave up. I thought it was much better to use the
IDE and build system suggested by the MCU manufacturer.
Now I'm trying a Unix shell in Windows (msys, WSL or even the bash
installed with git) and it seems many issues I had are disappearing.
And of course you will want an msys2/mingw64 (/not/ old mingw32) for
native gcc compilation.
The goal of the simulator is to detect problems on the software that
runs directly on Windows, without flashing, debug probes and so on. I increased my productivity a lot when I started this approach.
Obviously, the software running on Windows (the simulator) should be
very similar to the sofware running on the embedded target. Cortex-M
MCUs are 32-bits so I thought it should be better to use a 32-bits
compiler even for the simulator.
Moreover, I think many issues aries on a 64-bits compilation, for
example static allocated buffers that would be too small on a 64-bits platforms. Or some issues on serializers.
Don't bother with WSL unless you actually need a fuller Linux system -
and if you /do/ need that, dump the wasteful crap that is Windows and
use Linux for your development. Build speeds will double on the same
hardware. (In my testing, done a good while back, I did some
comparisons of a larger build on different setups on the same PC,
using native Windows build as the baseline. Native Linux builds were
twice the speed. Running VirtualBox on Windows host, with a Linux
virtual machine, or running VirtualBox on Linux with a Windows virtual
machine, both beat native Windows solidly.)
I completely agree with you. At the moment msys2 seems ok.
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.
It is an interesting and uncommon (at least for me) approach.
What happens if multiple developers work on the same repository? Are
they forced to create a host_xxx.mk for all their development machines? Should the host_xxx.mk files be added to the repository?
I guess the only goal of host_xxx.mk is to avoid changing PATH before
make. Why don't you like setting the PATH according to the project
you're working on?
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).
Yes, splitting makefiles is a good suggestion.
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.
I have to admit that ChatGPT helped me to create the Makefile. The
CFLAGS include -MMD and -MP and at the end I have
-include $(DEP_FILES)
Of course, DEP_FILES are:
DEP_FILES := $(OBJ_FILES:.o=.d)
Sincerely I don't know if it is good, but I tried to change an include
file and related C files are compiled again as expected (so I think the dependency are correctly managed).
There's a thing that doesn't work. If I change the Makefile itsel, for example changing CFLAGS adding a new compiler option, I need to manually invoke a clean.
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.
Yes, perfectly agreed.
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.
I don't think I got the point. Now I invoke the build of a single build configuration. Are you talking about running make to build multiple configurations at the same time?
Buona sera!
On Wed, 14 May 2025, pozz wrote:
"[. . .] When it comes to stupid and big IDEs [. . .]
[. . .]
It is already a miracle if that software runs without problems with the default
installation path. I don't want to imagine what happens if I changed it."
If these IDEs would not be trustworthy, then you would need to buy good alternatives.
Il 15/05/2025 11:03, David Brown ha scritto:
On 14/05/2025 23:51, pozz wrote:
Il 14/05/2025 11:03, David Brown ha scritto:
On 13/05/2025 17:57, pozz wrote:[...]
I worked on PIC8 and AVR8 and IMHO AVR8 is much better then PIC8.
Regarding Cortex-M, SAM devices are fine for me.
2.
You don't need to use bash or other *nix shells for makefile or
other tools if you don't want to. When I do builds on Windows, I
run "make" from a normal command line (or from an editor / IDE). It
is helpful to have msys2's usr/bin on your path so that make can use
*nix command-line utilities like cp, mv, sed, etc. But if you want
to make a minimal build system, you don't need a full msys2
installation - you only need the utilities you want to use, and they
can be copied directly (unlike with Cygwin or WSL).
Of course you /can/ use fuller shells if you want. But don't make
your makefiles depend on that, as it will be harder to use them from
IDEs, editors, or any other automation.
In the beginning (some years ago) I started installing GNU Make for
Windows, putting it in c:\tools\make. Then I created a simple
Makefile and tried to process it on a standard Windows command line.
It was a mess! I remember there were many issues regarding:
slash/backslash on file paths, lack of Unix commands (rm, mv, ...)
and so on. Native Windows tools need backslash in the paths, but
some unix tools need slash. It was a mess to transform the paths
between the two forms.
Most tools on Windows are happy with forward slash for path separators
as well.
mkdir, just to name one? And you need mkdir in a Makefile.
Certainly everything that is originally a *nix tool will be fine with
that.
Of course if you have a makefile that uses commands like "rm" and you
don't have them on your path, and don't specify the path in the
makefile, then it won't work. This is why the norm in advanced
makefiles is to use macros for these things :
# Put this in the host-specific file, with blank for no path needed
bin_path :=
# Use this instead of "rm".
RM := $(bin_path) rm
Initially I insisted using native Windows commands: DEL, MKDIR, COPY and
so on. Finally I gave up.
After this attempt, I gave up. I thought it was much better to use
the IDE and build system suggested by the MCU manufacturer.
For most IDEs, the build system is "make". But the IDE generates the
makefiles - slowly for big projects, and usually overly simplistic
with far too limited options.
But IDE's are certainly much easier for getting started. On new
projects, or new devices, I will often use the IDE to get going and
then move it over to an independent makefile. (And I'll often
continue to use the IDE after that as a solid editor and debugger -
IDE's are generally happy with external makefiles.)
I'm going to create a new post regarding editors and debugger... stay
tuned :-D
lmingw32Now I'm trying a Unix shell in Windows (msys, WSL or even the bash
installed with git) and it seems many issues I had are disappearing.
And of course you will want an msys2/mingw64 (/not/ old mingw32) for
native gcc compilation.
The goal of the simulator is to detect problems on the software that
runs directly on Windows, without flashing, debug probes and so on.
I increased my productivity a lot when I started this approach.
Obviously, the software running on Windows (the simulator) should be
very similar to the sofware running on the embedded target. Cortex-M
MCUs are 32-bits so I thought it should be better to use a 32-bits
compiler even for the simulator.
mingw-w64 can happily generate 32-bit Windows executables. IIRC you
just use the "-m32" flag. It is significantly better than old mingw
in a number of ways - in particular it has vastly better standard C
library support.
Why doesn't it work for me? I open a Msys2/mingw64 shell and...
$ gcc -m32 -o main.exe main.c C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/lib/libmingw32.a when searching for -
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/lib\libmingw32.a when searching for -lmingw32
...
... and much more
I guess the only goal of host_xxx.mk is to avoid changing PATH before
make. Why don't you like setting the PATH according to the project
you're working on?
No, that is not the only goal - there can be many differences between
machines. For example, I usually have ccache on my Linux systems but
it is rare to have it on (native) Windows systems - thus that can be
enabled or disabled in a host_xxx.mk file. Some machines might also
support building the documentation, or running a simulator, or signing
binaries.
Setting the path would be an extra complication of no benefit, but a
significant source of risk or error. How do you make sure your IDE is
using the right PATH settings before it runs "make"? How do you deal
with multiple projects - do you keep swapping PATHs? (I usually have
a half-dozen projects "open" at a time, in different workspaces on my
Linux machine.) Do you now have a makefile and a separate
path-setting batch file or shell script that you need to run before
doing a project build? How do you handle things when you install some
new Windows program that messes with your path?
It is /vastly/ simpler and safer to put the paths to the binaries in a
couple of macros in your makefile(s). It also gives clear and
unequivocal documentation of the tools you need - if your makefile
has this line :
toolchain_path := c:/micros/gcc-arm-none-eabi-10_2020-q4-major/bin/
then there is never any doubt as to exactly which toolchain is used
for the project.
I see your points. The only drawback seems putting a bunch of
host_xxx.mk files in the repository. If the developer team and their development machines are well defined and static, everything goes well.
However what happens when a new developer pulls your repository and want
to build? At first, he must create his host_xxx.mk and starting
polluting the original repository. Instead, by using the PATH, it could build without touching any files in the repo.
Maybe this isn't our situation, but a public open-source repository
can't use your approach. It's impossible to include in the public repository tenths or hundreds host_xxx.mk.
Moreover, what happens if two developers like astronomy and set the
hostname of their development machine JUPITER? Maybe one uses Linux,
the other Windows.
In your make, it seems you include the correct host_xxx.mk file
automatically from the hostname.
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.
I don't think I got the point. Now I invoke the build of a single
build configuration. Are you talking about running make to build
multiple configurations at the same time?
Yes.
Obviously it depends on the stage you are in development and the kind
of project - much of the time, you will want to build just one
configuration. But sometimes you will also want to make multiple
builds to check that a small change has not caused trouble elsewhere,
or for different kinds of testing? Why run multiple "make" commands
when you can do a full project build from one "make" ?
Are you thinking something similar to:
all_configs:
$(MAKE) -j 4 CONFIG=FULL
$(MAKE) -j 4 CONFIG=STANDARD
$(MAKE) -j 4 CONFIG=LITE
With my actual Makefile, "make all_configs" returns an errore because
CONFIG is not specified.
On Thu, 15 May 2025, David Brown wrote:
"There /are/ no alternatives that are more trustworthy - they
just have different failure or risk points. There can be benefits in buying a
commercial IDE, and/or a commercial toolchain, but lower risk of bugs, quirks or
installation issues is most certainly not one of them."
C and C++ compilers and codes produced thereby are not trustworthy. Use commercial Ada compilers to avoid bugs.
Il 16/05/2025 11:12, David Brown ha scritto:
On 15/05/2025 23:25, pozz wrote:
Il 15/05/2025 11:03, David Brown ha scritto:
On 14/05/2025 23:51, pozz wrote:
Il 14/05/2025 11:03, David Brown ha scritto:
On 13/05/2025 17:57, pozz wrote:[...]
I worked on PIC8 and AVR8 and IMHO AVR8 is much better then PIC8.
Regarding Cortex-M, SAM devices are fine for me.
The 8-bit PIC's are extraordinarily robust microcontrollers - I've
seen devices rated for 85 °C happily running at 180 °C, and tolerating
short-circuits, over-current, and many types of abuse. But the
processor core is very limited, and the development tools have always
been horrendous. The AVR is a much nicer core - it is one of the best
8-bit cores around. But you are still stuck working in a highly
device-specific form of coding instead of normal C or C++.
Why do you write "highly device-specific form of coding"? Considering
they are 8-bits (and C is at-least-16-bits integer), it seems to me an acceptable C language when you coimpile with avr-gcc.
You can use int variables without any problems (they will be 16-bits).
You can use function calls passing paramters. You can return complex
data from functions.
Of course flash memory is in a different address space, so you need
specific API to access data from flash.
Do you know of other 8-bits cores supported better by a C compiler?
And you are still stuck with Microchip's attitude to development
tools. (You can probably tell that I find this very frustrating - I
would like to be able to use more of Microchip / Atmel's devices.)
Maybe we already talked in the past about this. I don't know if avr-gcc
was developed by Atmel or Arduino community.
Anyway, for AVR8 you have
the possibility to use gcc tools for compiling and debugging. There are
many open source tools. I think you could avoid completely
Microchip/Atmel IDE for AVR8 without any problems. Arduino IDE is a good example.
2.
You don't need to use bash or other *nix shells for makefile or
other tools if you don't want to. When I do builds on Windows, I >>>>>> run "make" from a normal command line (or from an editor / IDE).
It is helpful to have msys2's usr/bin on your path so that make
can use *nix command-line utilities like cp, mv, sed, etc. But if >>>>>> you want to make a minimal build system, you don't need a full
msys2 installation - you only need the utilities you want to use,
and they can be copied directly (unlike with Cygwin or WSL).
Of course you /can/ use fuller shells if you want. But don't make >>>>>> your makefiles depend on that, as it will be harder to use them
from IDEs, editors, or any other automation.
In the beginning (some years ago) I started installing GNU Make for
Windows, putting it in c:\tools\make. Then I created a simple
Makefile and tried to process it on a standard Windows command
line. It was a mess! I remember there were many issues regarding:
slash/backslash on file paths, lack of Unix commands (rm, mv, ...)
and so on. Native Windows tools need backslash in the paths, but
some unix tools need slash. It was a mess to transform the paths
between the two forms.
Most tools on Windows are happy with forward slash for path
separators as well.
mkdir, just to name one? And you need mkdir in a Makefile.
Don't use the crappy Windows-native one - use msys2's mkdir. As I said:
bin_path :=
RM := $(bin_path) rm
MKDIR := $(bin_path) mkdir
and so on.
Now your makefile can use "mkdir" happily - with forward slashes, with
"-p" to make a whole chain of directories, and so on.
Yes, sure, now I know. I was responding to your "Most tools on Windows
are happy with forward slash". I thought your "tools on Windows" were
native Windows commands.
I think your suggestion is: explicitly call msys tools (rm, mkdir, gcc)
in normal Windows CMD shell, without insisting in using directly the
msys shell. Maybe this will help in integration with third-parties IDE/editors (such as VSCode, C::B, and so on).
I'm going to create a new post regarding editors and debugger... stay
tuned :-D
You are keeping this group alive almost single-handedly :-) Many of
us read and answer posts, but few start new threads.
I'm the student, your are the teachers, so it is normal I make the
questions :-D
[OT] I like newsgroups for chatting with others on specific topics.
Nowadays unfortunately newsgroups are dying in favor of other social platforms: Facebook, reddit, blogs.... Do you know of some other active platforms about embedded?
It looks like you don't have the 32-bit static libraries included in
your msys2/mingw64 installation - these things are often optional.
(It might be referred to as "multi-lib support".) I haven't used gcc
on Windows for a long time - most of my work is on Linux. But I'm
sure that you'll find the answer easily now you know it is the 32-bit
static libraries (libmingw32.a) that you are missing.
On many places they suggest to use msys2/mingw32 for generating 32-bits Windows binaries. For example here[1].
[1] https://superuser.com/questions/1473717/compile-in-msys2-mingw64-with-m32-option
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