[En-Nut-Discussion] nutconfig

[Harald Kipp]

duane ellis wrote:
> 
> The first problem is simple to describe: the enable/disable scheme used 
> by nutcomponent does not support expressions.

I think it does. However, to use this you need a bit knowledge about 
Lua. The usage of Lua had been criticized several times. In my opinion, 
no Lua knowledge is required to implement basic items for configuration. 
For advanced tasks, two options are available

1. Use of Lua scripts within the configuration files
(see automatic version detection)
2. Adding new keywords to nutcomponent.c
(see latest enhancement via "exclusivity")

The original eCos Configurator uses tcl, which I'm neither familiar with 
and experienced problems to get it running right on Win32. To that time 
I was also looking for a simple interpreter language with the following 
features (loosely ordered by priority):

a) Open Source, of course
b) Very low footprint (possibly running on 8 bit AVRs)
c) Easy to implement on many platforms
d) Well documented
e) Easy to learn the basics
f) Easy to enhance for special purposes
g) More modern than, let's say, BASIC
h) Reliable user base and support

Finally I found Lua, which fulfills all requirements, except that it is 
more memory hungry than expected. I now doubt that it can be implemented 
on 8 bit CPUs. But I also noticed, that it would make a powerful 
configuration language for Nut/OS. Gesagt, getan. I replaced tcl by Lua 
and the beast worked a few days later. The only real problem I can 
remember so far with Lua had been with the Linux distribution packs, so 
I recommended to build the library from the source. Luckily this seems 
to be solved nowadays.


> 
> The second problem is more complicated: The linux kernel configure 
> system also has an advantage that you load/save far more complete 
> (keyword: complete) configurations, and reconfigure based on a 
> previously saved configuration.

I'm not familiar with Linux kernel configuration, so I assume in the 
first place, that you are right. ;-) Despite my Lua advocacy above, I 
agree, that there may be better solutions.

> 
> Any ideas, or thoughts about how to solve these problems?
> 
> What about using, borrowing, or implementing some features of the linux 
> kernel configuration system?

Similar suggestion had been made by Ole lately. I'm open here and even 
offered to provide a translator. Though, it's not on top of my list, to 
replace a working Configurator (well, almost working :-)) with something 
I have no knowledge of or experience with. Nevertheless, as stated I'm 
ready to help, if someone starts this project.

Harald