[En-Nut-Discussion] Suggestion for (q)nutconf

[Thiago A. Corrêa]

Hi Ulrich,

    Actually all of those settings are handled by the "Multiple
configurations"  option.
    In qnutconf I have improved it a bit, as it doesn't only check for
filename but also for the file path as "key" for the multiple
configuration entry in the registry.

    Since different archs would have different .conf files, opening a
different .conf file would suffice.
    I use a structure like this in my development machine:
    /programming/ethernut
    /programming/comm5/firmware <-- my code

    With nutconf I have to do what you describe every time I loaded my
.conf file, since it resides with my code in a different branch than
ethernut/nut/conf. Now with qnutconf I can simply open the standard
.conf in nut/conf to test the boards supported in Nut/OS or my .conf
file and it will remember the settings for each. The problem of course
is the first time I open up the file, as it simply loads with it's
defaults.

> I think this is the best way to represent the easyness of nutos way of working:
> /nut
> /nutbld-avr-gcc
> /nutapp-avr-gcc
> /nutbld-stm32-gcc
> /nutapp-stm32-gcc
> /nutbld-arm-gcc
> ...
>
>
> They then can all coexist in peace and are not accidentially overwritten if you missed to rewrite all these settings every time you switch the architecture.

   If you build to diferent folders, there is a problem with the
Makedefs, config.mk, etc files for the samples, as it needs to be
re-generated to point to the proper folder. I usually rebuild over the
same folders so I can skip the "Build -> Create Sample Directory"
step.

   In my app makefiles I use relative paths and include those just
like the samples does. Not sure if that's the best way, but it works
for me. Wonder if others also do the same, or what would be the
recommended way anyway :)

Kind Regards,
    Thiago A. Correa