[En-Nut-Discussion] New build process

[Harald Kipp]

Hi Ole,


>But with playing around with nutconf I found a lot of minor or major
>problems:
>
>- Nutconf should have a command line interface to rebuild a buildtree...

Yes, this had been considered and was the reason for putting
the central part into a C file instead of C++. We simply need
someone with lots of time to write the missing main().

>- The's a problem with the nutconf makefile in CVS head. I've corrected
>   this.

Thanks.


>- Saving of a modified conf file does not work (needs to use saveas).

Might be a Linux related problem. In fact I created all conf
files with the tool, but on Win32. I'm not that experienced
with Linux file creation modes.


>- nutconf sometimes throws a segfault

Never experienced this...but again, I'm a bit overoriented
towards Windows.


>- nutconf often has drawing problems and selection of a value from a
>   dropdown box is only possible when using keyboard.

You have to keep the mouse on the left side of the list.
Seems to be a GTK problem.


>- the new build process does not support dependencies in the right way.
>   I always have to "make clean; make" even if I changed a file...

Right, but that had been a problem with Nut/OS from the
very first beginning. If you change a header file, the
command line make doesn't recognize this. So it's better
for now to use 'make clean' first. Someone have to spend
some hours to add 'make dep'.

>- The following files will not be compiled (since they are not yet
>   included into nutconf)
>   can-dev.c, sja1000.c, hd44780_bus.c, adc.c (thus all my additions to
>   NutOS)

Yes, Ole and believe me I'd have included them if there'd
have been more time. Btw. the Configurator allows to include
them to a specific compiler environment only. So if you are
not able to test them on ICCAVR, don't include them there.
This saves me from the burden to test every new contribution
for all environments.


>- The options for USART flowcontrole does not affect dev/usart0avr.c,
>   dev/usart0avr.c since these options went into include/cfg/arch/avr.h
>   and not into include/cfg/modem.h where they are expected to be.
>   Options for the RTS / CTS DDR registers are missing as other options
>   for handshake settings too.

Right, that's a bug.

>- Would be great if nutconf would only create one file every c file
>   would need to include. Nutconf only should save the option if the
>   default setting is overwritten. This way we would not need a new build
>   process and the dependencies would work again.

I do not agree here and I don't even think this is possible,
if I got you correctly. make is able to create dependency
files and why not use this feature.



>That's for the moment...
>
>For me I think Nutconf is a good approach, but not yet usable. At this
>moment it makes things more complicated and uncompfortable.

The Configurator and you need some more polish. Sorry,
I meant the tool needs polish and you need to get used to
it. :-)


>Harald, you may blame me :-) But even if it's not yet stable it's a
>quite good work.

I won't blame you at all but appreciate your comments
very much. As I said, it's not finished, but it's a
framework to continue with. If you look into the Lua
scripts, you will soon find out how to modify them.
They are so simple right now, that Lua knowledge is not
required. One hint: Beware the commas!

Harald