[En-Nut-Discussion] Features instead of Targets. was: memory boundary

[Harald Kipp]

This is a rather long reply. If you are familiar with
eCos or not interested in a nutconf replacement for
Nut/OS, skip this article. You won't miss something.
Nobody wants to scrap ./configure.


>I do agree that those #if defined()... lines should be shortened and based 
>on features not on architectures.
>so better define ARCH32 at a central place like in compiler.h instead of 
>several times whenever it is needed.

Right. But, be aware. I'm working on a complete new
solution, similar to the eCos configtool. In fact
I stole a lot of their code, but prefer not to take
over their complete tool (allthough it might work for
Nut/OS). Reasons:

- tcl is too complicated for such simple tasks. I plan
to use Lua

- I try to avoid C++ templates. They are elegant, but
the compilers/libs aren't smart enough. The eCos cdl
lib produces tons of warnings and you have to fiddle
with pragmas and tune compile options to get rid of them.

- No need to take over the historical leftovers from
the eCos tool. I'd like to start as simple as possible.

- The eCos tool overwrites parts of the wxWidgets class
lib, because they want to be saved from further changes.
My strategy has always been to arrange with existing
libs/tools and benefit from further development. (OK,
not for stdio.h and avr-libc, but that's another story.)

- For my taste, eCos packages are too much intermixed
with code. I'd like to keep the code compilable for users,
who refuse to use a GUI tool.

In case you don't know the eCos configtool:

It's a GUI, which presents a tree of options of various
types. You are able to load various prepared trees, mainly
by selecting a hardware platform, like the EB40A - or Ethernut 2
in our case.

In fact the options within a tree represent the different
packages, like, again in our case, the timer package with
an option to determine the clock frequency automatically
or specify a fixed one. An Ethernut clone without clock
crystal would have the automatic option disabled.

The whole tree is build from a set of tcl scripts, which
are mostly very simple, just setting variables or variable
structures.

Each eCos package comes with it's own set of tcl scripts.

After the user selected all options, he clicks a button
to create the build tree. That means, the tool is now
creating a set of C header files, Makefiles etc. Again,
the tcl package scripts specify, which files have to be
created in which format.

I can see a similar tool for Nut/OS, creating a set of
header files in include/cfg - and possibly some make
includes. Here I would prefer again, not to create the
Makefiles directly, but leave the existing ones intact.

Harald