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.
We currently default to "-mfloat-abi=hard -mfpu=fpv4-sp-d16" for M4F cores, and
and variations of "-mfloat-abi=soft" for the others. Keep the M4F default, and
move others to no FP flags for consistency, but allow overriding these flags
via the FP_FLAGS environment variable.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
previously, only stm32 chips passed the information about which chip to
build on into the compiler. this information is essential to dispatch,
thus defining LPC13XX, LPC17XX, LPC43XX and LM3S in analogy to
STM32F1..4.
vector.o, nvic.o, scb.o and assert.o are available on every platform,
but at least some of them differ between the implementations. they
already got built explicityly on some platforms; now adding them to the
common Makefile.include.
Adds libopencm3/cm3/assert.h header that provides assertion check macros
similar to those provided by the standard C library.
Thanks to Nicolas Schodet for help.
- The library files are now being built into the lib subdirectory of the
source.
- The linker files for each library are being copied into the lib source
subdirectory.
Motivation: The relative locations of files in the source directory after make
are now the same as after make install now. This makes it easier to
reuse examples with their makefiles outside of the libopencm3
sourcecode directory.
Karl Palsson
Christian Tacke
George Jiglau
Jonas Meyer
Frantisek Burian
Felix Held
Alexandru Gagniuc
Gareth McMullin
Gareth McMullin
Piotr Esden-Tempski
chrysn
Tomaz Solc
Taylor Vesely