Meson build

[perigoso]

Why

This is not a real PR, not for now at least, merely for review and evaluation purposes

I decided to make a quick draft meson build for black magic firmware, to aid in the evaluation of the future buildsystem rework, also because I was bored and enjoy it

I realize all this work may be scrapped, that is fine

What

At the moment only the native probe target and the stm32 platform are implemented, the libopencm3 dependency is not properly handled

How

because libopencm3 is not being handled properly yet, we need to build it manually first

make -C libopencm3 lib/stm32/f1 lib/stm32/f4 lib/lm4f

we create a build directory, where the build configuration and compilation will happen

mkdir build

configuring the build, the default target probe is the native we may configure the target probe with -Dprobe=some_probe in the event that a unsupported probe is configured, a message will be displayed with available probes (although they wont compile right now), the crossfile here tells meson we're cross compiling and selects the toolchain

meson build/ --cross-file crossfile/arm-none-eabi.ini

meson build/ --cross-file crossfile/arm-none-eabi.ini -Dprobe=testing_invalid_probe
Message: Available target probes: ['f4discovery', 'swlink', 'stlink', 'hydrabus', 'native', 'launchpad-icdi', '96b_carbon']
ERROR: Problem encountered: The target probe testing_invalid_probe is not a valid probe

finally we deply the ninjas (we build)

ninja -C build/

This should generate a valid binary for the native hardware (build/black_magic_firmware.bin), I haven't tested it, fair warning, but the binary looks valid at a glance, I also tried to make the build as similar option for option to the original as i could

[perigoso]

Added some fancy user feedback for the build configuration and added target enabling/disbling funtionality, I'm pretty happy with this right now, it still needs porting of the rest of platforms and probes

example run with the current configuration, using the default probe and enabling only support for stm:

[rafael@rafaelsilva-work-laptop build]$ meson .. --cross-file ../crossfile/arm-none-eabi.ini -Dtargets=stm

The Meson build system
Version: 0.62.2
Source dir: /home/rafael/Development/blackmagic
Build dir: /home/rafael/Development/blackmagic/build
Build type: cross build
Project name: Black Magic Firmware
Project version: v1.8
C compiler for the host machine: arm-none-eabi-gcc (gcc 12.1.0 "arm-none-eabi-gcc (Arch Repository) 12.1.0")
C linker for the host machine: arm-none-eabi-gcc ld.bfd 2.38
C compiler for the build machine: ccache cc (gcc 12.1.0 "cc (GCC) 12.1.0")
C linker for the build machine: cc ld.bfd 2.38
Build machine cpu family: x86_64
Build machine cpu: x86_64
Host machine cpu family: x86_64
Host machine cpu: x86_64
Target machine cpu family: x86_64
Target machine cpu: x86_64
Message: The target "stm" depends on "cortexm", but this target is not enabled, enabling
Library libopencm3_stm32f1 found: YES
Program arm-none-eabi-size found: YES
Program arm-none-eabi-objcopy found: YES
Build targets in project: 7

Black Magic Firmware v1.8

  Targets
    enabled    : stm
                 cortexm
    disabled   : cortexa
                 efm
                 lpc
                 nrf
                 nxp
                 rp
                 sam
                 ti

  Probe
    active     : native
    demo       : just a demo info for probes

  Platform
    active     : stm32
    family     : stm32f1

  User defined options
    Cross files: ../crossfile/arm-none-eabi.ini
    targets    : stm

Found ninja-1.11.0 at /usr/bin/ninja
Cleaning... 0 files.

[rafael@rafaelsilva-work-laptop build]$ ninja size

[39/40] Running external command size (wrapped by meson to set env)
   text    data     bss     dec     hex filename
  41968     292    3036   45296    b0f0 /home/rafael/Development/blackmagic/build/black_magic_firmware.elf

I used I feature I hadn't before in meson, dictionaries, for the targets in the targets meson file, I think it works pretty well for it, the way it's done now allows us to do some cool stuff like enabling targets that are dependencies of other targets and doing something like target groups, to enable a group of targets with a single keyword on configuration

This isn't tested in hardware, so I don't know that this method of disabling targets works, but i believe it should

[perigoso]

all platforms and probes available ported, unknown if they actually work, but they build, might need some tweaking

[perigoso]

superceeded by #1528