[build] Add Makefile build script generator

[salkinium]

Makefiles are quite simple to use and I wanted a build system that didn't require Python3 (at least for building, all our tooling requires it of course). It may also make it easier for people wary of SCons or CMake to use modm.

• Compilation and linking of .elf file
• Compilation of source files with custom flags
• Merging of Makefile generated by::cmake (almost identical) CMake Makefile will go away soon.
• Move all special tools from :::scons to ::build and also implement in :::make
  • unit test tool
  • information tool
  • bitmap tool
• Add Makefile generator to examples
• Test Makefile Tools
  • Bitmap tool
  • infomation tool: git + build
  • unit test
  • program, program-bossac, program-fuses, program-dfu
  • debug, debug-coredump with ui=tui and ui=web
  • reset
• Documentation

cc @rleh @chris-durand

[rleh]

• Merging of Makefile generated by ::cmake (almost identical)

I never understood why there is a Makefile generated by the cmake generator. With the rework of the cmake generator in #568 it will probably disappear?!

[rleh]

Looks nice and clean! 👍🏽

(and I like Makefiles 😆)

[salkinium]

Ok, this is ready for review now. It's a copy of the SCons "API" with all features except make artifact and there's no XPCC integration.

[salkinium]

Ah, of course, using shell commands doesn't work on Windows. That's going to be annoying…

Compiling C++·· release/modmsrcmodmdebugloggerhosteddefault_style.omkdir: unknown option -- M
74
Try 'mkdir --help' for more information.

[salkinium]

Ok, so now that I have a Windows VM I can say that generating a Windows-compatible Makefile requires dealing manually (!!!) with the path seperator \ vs / incl. in generated paths (ie. make does not care either). I've therefore decided not to care about Windows support for the Makefile generator (ie. you can use SCons or CMake) and will simply put a big warning about not using it on Windows.

[salkinium]

This is ready for merging, unless someone™ wants to review.

[salkinium]

I added an alias mechanism to lbuild v1.16.0 so that the move of :build:scons:info.git to :build:info.git is backwards compatible and prints a warning about what happened.

 $ lbuild -D :build:scons:info.git=Info discover -t :build:scons --developer
[WARNING] lbuild.node: Node 'modm:build:scons:info.git' has been moved to ':build:info.git'!

>> modm:build:scons:info.git  [Alias]

Moved into `modm:build` module

Alias: :build:info.git

>> modm:build:info.git  [EnumerationOption]

# Generate git repository state information

- `Info`: generates information about the last commit.
- `Info+Status`: like `Info` plus git file status.

Value: Disabled
Inputs: [Disabled, Info, Info+Status]

Module(modm:build:scons)   SCons Build Script Generator
├── Option(cache_dir) = [] in [Path]   Path to SConstruct CacheDir
├── Option(include_sconstruct) = True in [True, False]   Generate a SConstruct file
├── Option(path.artifact) = artifacts in [Path]   Path to Artifact Store
├── Collector(flag_format) in [Callable]   Formatting compile flags for SCons
├── Collector(path.tools) in [Path]   SCons tool paths to be added to the Environment
├── Collector(tools) in [String]   SCons tools to be added to the Environment
├── Alias(image.source) -> :build:image.source   Moved into `modm:build` module
├── Alias(info.build) -> :build:info.build   Moved into `modm:build` module
├── Alias(info.git) -> :build:info.git   Moved into `modm:build` module
╰── Alias(unittest.source) -> :build:unittest.source   Moved into `modm:build` module

[salkinium]

Ping @rleh, please review so I can merge…

[rleh]

Make uses the build folder make-release/, so scons should also use scons-release/ (currently release/).

[rleh]

With the stm32f469_discovery/hard_fault example the *.elf files are different, the one produced by Make is 228 Bytes smaller.

[salkinium]

The interesting question is if the .bin file is different? I would assume so perhaps because of link order…

[rleh]

Suggested change

	using LedD13 = GpioA17;
	using LedTx = GpioA27;
	using LedRx = GpioB03;
	using Leds = LedTx;
	// User LED (Rx and Tx LEDs inverted, because connected to 3V3)
	using LedD13 = GpioA17;
	using LedTx = GpioInverted<GpioOutputA27>;
	using LedRx = GpioInverted<GpioOutputB03>;
	using Leds = SoftwareGpioPort< LedTx, LedRx >;

https://cdn.sparkfun.com/datasheets/Dev/Arduino/Boards/sparkfun-samd21-mini-breakout-v10.pdf

[salkinium]

I know, but the problem is that the SAM GPIO implementation does not have GpioInverted or SoftwareGpioPort implemented…

[rleh]

Ohhh :D

Maybe we (you) should create a issue about that and add the "help wanted" label?

[salkinium]

If I'm honest I would rather rework the Targets support matrix to something that's generated from lbuild using the data we already accumulate in generate_module_docs (but perhaps not so slow). That would give a much more detailed look at what peripherals are supported.

[salkinium]

Also not sure if the "help wanted" is generally useful, so far I've not seen a contributor specifically fix things they are not personally motivated to do.

[rleh]

I think this is also because we hardly have such "help-wanted" problems that are suitable for beginners.
We could also try to participate in events like hacktoberfest to attract new contributors.

[rleh]

The interesting question is if the .bin file is different? I would assume so perhaps because of link order…

Bin (and hex) files differ only slightly, probably because of GCCs build id?

I think that's fine!