I'm trying to compile an existing project that has structure like so:
source/device.c
source/folder1/device.c
source/folder2/device.c

Using the rules in this repo, the project won't build properly because all each of the files above get compiled to build/device.o.

I'm not really expecting the team to redo your make files to accommodate this
But I could use your advice on what you'd do here.

In base_tools, recipes with this definition will fail silently if bin2s is not installed (Make will incorrectly think it succeeded).

define bin2o
	bin2s -a 4 -H `(echo $(<F) | tr . _)`.h $< | $(AS) -o $(<F).o
endef

This happens because the exit code of bin2s is ignored, which happens because it's on the left side of a pipe.

This can be fixed by setting pipefail. Here's one way to do it:

	set -o pipefail; bin2s -a 4 ...

Note that this is a bash-ism, so it will not work on other shells. That may be a portability concern.

I ran into this issue when experimenting with C++20 modules, when a module's extension was .cppm.

I was confused at first, until I realized that, due to the rules files, the makefile recipes don't take into account this wacky new feature and its possible file extensions (.ixx/.cppm/etc). Compiling the modules works if the module extensions are .cpp. However, some IDEs expect or REQUIRE the modules to NOT have .cpp as an extension for some analysis features to work.

As you can tell, Clion accepts the module syntax just fine in this file but presumably it cannot "smartly" detect usage of the module in other files.

I'm sure this could be resolved by simply adding a recipe for .cppm and/or .ixx. I understand if this is not an important issue as C++20 modules are still uncharted territory compared to other new C++ features such as constexpr and concepts, but it would be cool to support this feature.

the latest release doesnt have devkitarm-rules-1.2.1.tar.gz, only the source code.tar.gz, so the build scripts broke

Running make with multiple jobs like make -j{multiple_jobs} generates mixed up, invalid compile_commands.json.

Reproduce

You can easily reproduce this with multiple empty source files, and run make -j{multiple_jobs}
I created empty test000.c ~ test100.c in the gba template for the test

Result

[
{
"directory": "/opt/devkitpro/examples/gba/template/build",
,
{
"directory": "/opt/devkitpro/examples/gba/template/build",
"command": "/opt/devkitpro/devkitARM/bin/arm-none-eabi-gcc  -g -Wall -O2 -mcpu=arm7tdmi -mtune=arm7tdmi -mthumb -mthumb-interwork -iquote /opt/devkitpro/examples/gba/template/include -I/opt/devkitpro/libgba/include -I/opt/devkitpro/examples/gba/template/build -c /opt/devkitpro/examples/gba/template/source/test000.c -o test000.o",
"file": "/opt/devkitpro/examples/gba/template/source/test000.c"
}
,
,
{
{
"directory": "/opt/devkitpro/examples/gba/template/build",
"directory": "/opt/devkitpro/examples/gba/template/build",
"command": "/opt/devkitpro/devkitARM/bin/arm-none-eabi-gcc  -g -Wall -O2 -mcpu=arm7tdmi -mtune=arm7tdmi -mthumb -mthumb-interwork -iquote /opt/devkitpro/examples/gba/template/include -I/opt/devkitpro/libgba/include -I/opt/devkitpro/examples/gba/template/build -c /opt/devkitpro/examples/gba/template/source/test002.c -o test002.o",
"file": "/opt/devkitpro/examples/gba/template/source/test002.c"
}
"command": "/opt/devkitpro/devkitARM/bin/arm-none-eabi-gcc  -g -Wall -O2 -mcpu=arm7tdmi -mtune=arm7tdmi -mthumb -mthumb-interwork -iquote /opt/devkitpro/examples/gba/template/include -I/opt/devkitpro/libgba/include -I/opt/devkitpro/examples/gba/template/build -c /opt/devkitpro/examples/gba/template/source/test001.c -o test001.o",
"file": "/opt/devkitpro/examples/gba/template/source/test001.c"
}
,
// omitted

when this gets called from build_crtls.sh (which is called from build_devkit.sh), regardless of what the actual top-level $INSTALLDIR is, the rules get copied to /opt/devkitpro/devkitARM as opposed to $INSTALLDIR/devkitpro/devkitARM (which then makes things explode when all our arm rules are "missing" in /opt instead of under $DEVKITARM)

TLDR;

• $DESTDIR is not set when this is invoked
• this ignores the top level installation prefix that is set in build-devkit.sh
• it results in install/builds failing due to none of the rules being where it expects.

What is the right way to fix this? I'm happy to do a PR, to solve my problem i just patched the Makefile to use $INSTALLDIR instead, but i'm not sure thats correct for all the automated pacman packaging etc.