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

[Ulrich Prinz]

Hi!

Am 21.10.2010 18:01, schrieb 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
>
Yes, but my idea makes this saving in the registry obsolete and the
configuration can be spread across multiple working places of me and my
collegues. This makes it easy to support beginners in their first steps
as the project.conf files ( I save the .conf files in the project
directories too) are checked in into the projects SVN.

> 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 didn't see this over here, but I didn't test the Multiple Config
option in qnutconf. I just expected the unclear to me behavior of
nutconf behind it.

>> 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 different 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.
>
But if you do low level development, this is what you need as you like 
to compare builded libraries, list files and some times even compare the 
compiler output. That's why I prefer the old naming convention of the 
Nut/OS examples. But nevertheless I use the placement for the project 
files like you:

Create the example directories, copy the example that matches best ( or 
take the usart example) and rename the directory to the project name.
Now my project is under .../nutapp-stm32-gcc/myproject. In that way I 
have no trouble by copying over Makefiles and their dependencies.

> 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 :)
>
Hmm, we are doing the same and that is what Harald told to be the best way.

But I rely on having separate architecture specific files. That makes it 
obsolete to any time refresh the Makefiles in the architecture specific 
application directory.

So I can build Nut/OS for ARM7 and create the app directory and get
nutbld-arm-gcc and nutapp-arm-gcc.
Then I repeat that for STM32F and get nutbld-stm-gcc and nutapp-stm-gcc.
I checkout EIR code to nutapp-arm-gcc and copy it over to nutapp-stm-gcc.
Then I can get edit and recompile on both builds and applications 
without having to restart/reload nutconf and merge the application 
modifications crosswise.

Ok, I agree, this you do only if you have two widescreens on your pc, 
and if you start the debugger you wish you can add another one...
But its fast, simple and lets you find the most problems.

So if I enable 'Multiple Configurations' I can do that without having to 
keep an eye on the compiler and programmer settings?

Best regards
Ulrich