When piping to a file, if arm-none-eabi-gcc is not present in the path,
a blank linker script is created with genlink. After sourcing a bash
script to add GCC to the path, the linker script doesn't get rebuilt
due to a fresh timestamp despite failing to generate.
Fixes: 96d094af13 mk/genlink-config: provide LIBNAME in devices autogeneration
The initial fix had fixed the examples repo, but broke the tests and the
template repo. Restore the suffix properly.
This makes the generic rules workk happily regardless of whether the
linkerscript generation is being used or not.
Notably, in the examples repo, use of the linker script autogeneration
was retriggering library builds as LIBNAME was unset and therefore the
libraries lib<blank>.a couldn't be found.
If $(OPENCM3_DIR)/lib/libopencm3_*.a exists, it will be linked in.
If we do that, we should also add it to the deps.
That way a newer *.a will result in a relink.
To use this, you should add a dependency to $(LIBDEPS) where you are
using $(LDFLAGS) and $(LDLIBS) now.
eg, old (wouldn't relink if the library changed)
$(PROJECT).elf: $(OBJS) $(LDSCRIPT)
@printf " LD\t$@\n"
$(Q)$(LD) $(TGT_LDFLAGS) $(LDFLAGS) $(OBJS) $(LDLIBS) -o $@
new (will relink when the library changes)
$(PROJECT).elf: $(OBJS) $(LDSCRIPT) $(LIBDEPS)
@printf " LD\t$@\n"
$(Q)$(LD) $(TGT_LDFLAGS) $(LDFLAGS) $(OBJS) $(LDLIBS) -o $@
Tested-by: Karl Palsson <karlp@tweak.net.au>
Originally tracked via: https://github.com/libopencm3/libopencm3/pull/887
Until https://github.com/libopencm3/libopencm3/issues/732 has been
fixed, it's not enough to just have it in the README that you need GNU
awk. Explicitly use the "gawk" command name. This exists on (sane)
systems that have gawk as awk, and for systems that use mawk as default,
the gawk name should also exist.
This should make it significantly easier to diagnost the cause of build
problems.
As discussed with karlp on irc the devices.data file should not contain
gcc specific command line options.
For that reason the command line options for gcc are now generated from
the variables CPU and FPU by the rules in the mk directory.
This breaks the genlink tests.
genlink: simplified devices.data
devices.data already had the information about the family name.
By using the first field (by the pattern used to match it) as family name information that data doesn't
have to be provided explicitly. The same data is used to generate the
CPPFLAGS, such as -DSTM32F1
The architectures block of the devices.data file was redundant.
genlink-config.mk uses family and subfamily to figure out which libopencm3
variant actually exists.
Denis Feklushkin