b88561299b
In the current compilation environment, the recursive assignment(=) for compile
flags will be delayed until every file is actually need to be compile.
For example:
--------------------------------------------------------------------------------
arch/arm/src/Makefile:
INCLUDES += ${shell $(INCDIR) "$(CC)" $(ARCH_SRCDIR)$(DELIM)chip}
INCLUDES += ${shell $(INCDIR) "$(CC)" $(ARCH_SRCDIR)$(DELIM)common}
INCLUDES += ${shell $(INCDIR) "$(CC)" $(ARCH_SRCDIR)$(DELIM)$(ARCH_SUBDIR)}
INCLUDES += ${shell $(INCDIR) "$(CC)" $(TOPDIR)$(DELIM)sched}
CPPFLAGS += $(INCLUDES) $(EXTRAFLAGS)
CFLAGS += $(INCLUDES) $(EXTRAFLAGS)
CXXFLAGS += $(INCLUDES) $(EXTRAFLAGS)
AFLAGS += $(INCLUDES) $(EXTRAFLAGS)
--------------------------------------------------------------------------------
All compilation options will be included recursively,
which will be delayed until the compilation options are actually used:
tools/Config.mk:
--------------------------------------------------------------------------------
define COMPILE
@echo "CC: $1"
$(Q) $(CC) -c $(CFLAGS) $($(strip $1)_CFLAGS) $1 -o $2
endef
--------------------------------------------------------------------------------
All compile flags to be reexecuted $(INCDIR) as long as one file needs to be compiled,
but in fact, the compilation options have not changed in the current directory.
So the we recommand to change the syntax of assignment
From
Recursive (=)
To
Simple (:=)
In this way, we can ensure that all compilation options are expanded only once and reducing repeated works.
Signed-off-by: chao.an <anchao@xiaomi.com>
|
||
|---|---|---|
| .. | ||
| configs/nsh | ||
| include | ||
| scripts | ||
| src | ||
| Kconfig | ||
| README.txt | ||
STATUS
======
05/17: The basic NSH configuration is functional and shows that there is
3-4KB of free heap space. However, attempts to extend this have
failed. I suspect that 8KB of SRAM is insufficient to do much
with the existing NSH configuration. Perhaps some fine tuning
can improve this situation but at this point, I think this board
is only useful for the initial STM32 F0 bring-up, perhaps for
embedded solutions that do not use NSH and for general
experimentation.
There is also support for the Nucleo boards with the STM32 F072
and F092 MCUs. Those ports do not suffer from these problems and
seem to work well in fairly complex configurations. Apparently 8KB
is SRAM is not usable but the parts with larger 16KB and 32KB SRAMs
are better matches.