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.
Christian Tacke
George Jiglau
Karl Palsson
Jonas Meyer
Anatol Pomozov
Frantisek Burian