[En-Nut-Discussion] Configuration: Is there something like a "forced" macro?
harald.kipp at egnite.de
Fri Oct 5 11:39:57 CEST 2012
On 04.10.2012 20:46, Uwe Bonnes wrote:
> Harald> I kept symbols starting with HW_ exclusively reserved for
> Harald> hardware provisions/requirements in the Configurator. IMHO, this
> Harald> makes it easier to handle the large number of symbols in the
> Harald> configuration files, specifically with global searching. I never
> Harald> use macro names starting with HW_.
> You critises the dummy implementation with dummy name, but you don't talk
> about the proposes idea.
Beware! I did not criticize, I just explained how I'm handling this.
> That way we could get rid of all the inclusion on top of include/dev/board.h
> and only have
> #if defined(PLATFORM_HEADER)
> #include PLATFORM_HEADER
Now I got it. I'm afraid, AFAIK, C89 doesn't provide macro expansion in
> People can then locally have any board.h file, without the need to edit
> board.h. At the moment above code and similar formulations are ignored. I
Similar discussion regularly take place in the avr-libc mailing list and
in many other project teams. IMHO, for generating better code, language
extensions are acceptable, but should be accompanied by alternatives for
compilers, which do not support them.
But we shouldn't give up C89 compatibility just for the convenience of
developers. Beside prominent members for PCs like MSC, many compilers
for rarely used embedded targets do support C89 only with a few C99
extensions, e.g. ImageCraft (PSoC and more), VSIDE (VSDSP) and there are
probably more. Btw, although most advanced, not even the latest GCC
supports the full standard:
> stared at nutcomponent.c for some time, but didn't see any chance to
First you need to become familiar with part IV of
and try a few samples on your own. The tricky part with nutcomponent.c
is, that it started as a pure static solution. Support for dynamic
content had been hacked in later.
More information about the En-Nut-Discussion