[En-Nut-Discussion] NutOS configurator

[Ole Reinhardt]

Hi Harald,

sorry for answering that late, but I've been quite busy last week so had
to work on other things.

> most of the time I'm still using Windows to build Nut/OS. However, 
> several workstations in our company are Debian Edge now and the 
> Configurator will be used more often on Linux. As far as I can say, it's 
> working acceptable.

Perhaps my problem is, that I'm working with Debian/Unstable to have all
other software up to date. I only use packages available in the Debian
repository, so my wxwidgets version is 2.6.xxx

> Neverthelee, speaking like a politician: "I'm very happy that we you are 
> criticizing this." :-) Well, actually I had the feeling that Linux users 
> are not happy with the Configurator. But as long as no one is 
> complaining, not much attention is paid.

Yes, it seems there are not that linux users in the NutOS community.
Second problem is, that linux users perhaps will search "an other
solution" if anything does not work like expected.

> There had been problems with the Configurator from time to time on both 
> platforms. They are mainly caused by directory path problems. Lua is 
> extremely stable and never ever caused any problems here. Not sure, if I 
> like this language really, but the runtime is very small, the code is 
> very well done and highly portable, and it seems to be quite powerful, 
> specially when used with C and C++.

I don't see the problem in lua, but more in wxwidgets and the different
different handling of directory pathes on linux / windows.

> If you are using wxWidgets 2.6, that _may_ cause trouble as well. Better 
> try the latest 2.8.

Unfortunately 2.8 is not available as package for Debian / Unstable.

>  There are still problems on Linux sometimes, but 
> nothing that really hurts. Sometimes the windows are not properly sized. 
> Resizing the main window or maximize and restore will help. The 
> Configurator inherited some very special controls from the original ecos 
> config. Over the time GTK and wxWidgets changed a lot and some features 
> used by these special controls did change as well. Anyway, as explained, 
> this is no big deal and can be fixed sooner or later. Btw. your are 
> using the latest Configurator from CVS HEAD or Nut/OS 4.4, aren't you?

Yes, I use CVS Head. I needed some modifications to make it running with
wxWidgets 2.6. 

I mainly have problems with path settings that are not found and
secondly the problem is, that the settings saved in ~/.NutConf are lost
from time to time when the path settings are not correct.

> Problem number 1 is this, however: We are using the autotools to build 
> the source package from CVS. Unfortunately CVS root is 'nut', while the 
> Windows installation is ethernut-x.y.z, where 'nut' is a subdirectory 
> of. This difference in the directory structure caused problems all the 
> time. Something got fixed on Windows, but caused problems on Linux and 
> vice versa.

Ok, what's about the following proposal:

Save global settings in the conf file, not in a global ~/.NutConf.
Always use a relativ path, so that starting from the conf file the
directory structure is known.

For me it seems that there is no consistent handling of the source and
buld path.

> IMHO, the best solution would be to get the same directory structure on 
> both platforms. In other words, ethernut-x.y.z is the top installation 
> directory and the location to start all build tools from. Directory nut 
> is just the source tree below the installation directory. But I'm not 
> using autotools too often and have no idea what's the smartest way to 
> get this done.

If you use cvs snapshots, you'll never have a consitent version
numbering. So using a directory calles ethernut-x.y.z is'nt a smart
solution.

But I would suggest something similar

-NutOS+
      |   
      nut+...
      |  |... 
      |
      build+...
      |    |...
      | 
      examples+...
              |...

This directory structure could be used for all supported platforms.

> Last not least, I have no objections to use a different tool like 
> kconfig. Of course we must avoid maintenance of two different 
> configuration scripts. It's already a nasty task to keep the Makefiles 
> up-to-date for native building in the source tree. Probably kconfig 
> configurations can be converted to Lua parts or vice versa or both may 
> be build from a global XML format or whatever.

I know, it's not an easy task to switch from one tool to another.
Basically Kconfig files and the NutConf config files are not that
different. The idea is the same.

I would be voluntary to set up a basic build environment for NutOS based
on Kconfig. Then we could evaluate what is a better solution and ask the
community to decide.

> P.S.: Somewhat off topic. While talking about tools, I was recently 
> forced to use scons
> http://www.scons.org/
> I was impressed. The only problem is, that it requires Python, which 
> caused some minor problems on Windows, which doesn't handle dependencies 
> very well. Anyway, it worked like a charm.

Never heard about it, but seems to be interesting. Python on windows
should be a solvable problem.

Bye,

Ole Reinhardt

-- 
 _____________________________________________________________
|                                                             |
| Embedded-IT          Hard- und Softwarelösungen             |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        +49 (0)271  7420433 |
| Luisenstraße 29      Mobil:             +49 (0)177  7420433 |
| 57076 Siegen         eMail:    ole.reinhardt at embedded-it.de |
| Germany              Web:         http://www.embedded-it.de |
|                      UstID / VAT:       DE198944716         |
|_____________________________________________________________|