[En-Nut-Discussion] NutOS configurator
Ole Reinhardt
sorry to say, but running NutOS configurator on linux is a mess.
Sometimes it partly does what it's mentfor, most times it does not.
Here are my current problems:
- On my platform currently no selections are shown at all, the tree is
completely empty.
- Path settings are forgotten always and the configurator never finds
it's repository.nut. Whatever I do it won't find the right path, even
if I reconfigure it correctly.
- On luky days it works a little bit better. In this case I "only" have
to load the configuration twice to see all options and be able to
generate the build tree.
Does anyone have better experiences on the linux platform?
I don't understand whet the problem might be. Is it a lua problem? A
wxwidgets problem? For me it's quite unusable. The commandline options
is not far what I need as I have to change options from time to time.
My platform:
debian/unstable
wxwidgets 2.6
lua5
As I have these problems from the day the configurator was born on, I'm
thinking about a better solution.
What's about using a good working tool like kconfig? It's available on
every platform NutOS can be build on, has several frontends (text based,
gui, etc...) and in fact does the same like the configurator. It's even
more simple to add new options then in nutconf.
I know, I just asked this question some time ago but would like to
discuss this again.
Sorry for my bad optinion about nutconf, but I never made it working ok
on the linux platform.
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.re...@embedded-it.de |
| Germany Web: http://www.embedded-it.de |
| UstID / VAT: DE198944716 |
|_____________________________________________________________|
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Alain M.
Ole Reinhardt escreveu:
> As I have these problems from the day the configurator was born on, I'm
> thinking about a better solution.
>
> What's about using a good working tool like kconfig? It's available on
> every platform NutOS can be build on, has several frontends (text based,
> gui, etc...) and in fact does the same like the configurator. It's even
> more simple to add new options then in nutconf.
Are you saying that you are considering abandoning lua? are you looking
for a new script language (like python) or a compiler (like Delphi that
runs as freepascal on linux, or Qt)?
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Vesa Jääskeläinen
> What's about using a good working tool like kconfig? It's available on
> every platform NutOS can be build on, has several frontends (text based,
> gui, etc...) and in fact does the same like the configurator. It's even
> more simple to add new options then in nutconf.
I wasn't aware that either kconfig (or kbuild) used on Linux kernel
build or KDE's KConfig has native versions running on Windows? Which one
were you talking about, or perhaps yet another? I tried to google for
kconfig but didn't find any good sources, perhaps you can share URL?
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Harald Kipp
> Does anyone have better experiences on the linux platform?
>
> I don't understand whet the problem might be. Is it a lua problem? A
> wxwidgets problem? For me it's quite unusable. The commandline options
> is not far what I need as I have to change options from time to time.
>
> My platform:
>
> debian/unstable
> wxwidgets 2.6
> lua5
>
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.
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.
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++.
If you are using wxWidgets 2.6, that _may_ cause trouble as well. Better
try the latest 2.8. 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?
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.
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.
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.
Harald
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.
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Tim DeBaillie
We used the windows NutConf until recently. However, it takes some time
to build in Windows (about 2 minutes). Many of us Ubuntu (Feisty Fawn),
so we decided to get the NutConf setup in Linux.
The ONLY problem we have had with it is that it NEVER loads with the
proper display. But then all you have to do is resize the window and
everything appears. This is not a video driver problem, as it has
happened on many different cards of different manufacturers.
Anyways, we have found that building with "relative paths" takes about 1-2
minutes. However, building with "absolute paths" takes about 8 seconds!!!
Interesting little "feature", but it makes recompiling the OS in Linux
worth your time to get setup properly.
When I get to the office on Monday, I can send the versions of the
software we are using. I will also send the instructions we used to
install it. We used a hybrid of what's on the Ethernut website and what
we found somewhere else about getting ARM7 working for GCC.
By the way, we have only used ethernut for the SAM7X and the SAM7S.
--
Tim
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Tim DeBaillie
> When I get to the office on Monday, I can send the versions of the
> software we are using. I will also send the instructions we used to
> install it. We used a hybrid of what's on the Ethernut website and what
> we found somewhere else about getting ARM7 working for GCC.
This is partially derived from:
http://www.ethernut.de/en/documents/debian.html
Install the following packages from the "Synaptics Package Manager", my
version number is in parentheses:
gcc (4.1.2-0ubuntu4)
g++ (4.1.2-0ubuntu4)
autoconf (2.61)
automake (1.10)
libwxgtk2.8-0 (2.8.1.1-0ubuntu4)
libwxgtk2.8-dev (2.8.1.1-0ubuntu4)
wx2.8-headers (2.8.1.1-0ubuntu4)
wx-common (2.6.3.2.1.5ubuntu6)
libgtk2.0-0 (2.10.11-0ubuntu3)
libgtk2.0-common (2.10.11-0ubuntu3)
libgtk2.0-dev (2.10.11-0ubuntu3)
libwxgtk2.4-1 (2.4.5.1ubuntu2)
libwxgtk2.8-0 (2.8.1.1-0ubuntu4)
libwxgtk2.8-dev (2.8.1.1-0ubuntu4)
lua50 (5.0.3-2build1)
liblua50 (5.0.3-2build1)
liblua50-dev (5.0.3-2build1)
liblualib50 (5.0.3-2build1)
liblualib50-dev (5.0.3-2build1)
doxygen (1.5.1-1build1)
doxygen-doc (1.5.1-1build1)
graphviz (2.8-2.6)
texinfo (4.8.dfsg.1-4build1)
libncurses5 (5.5-5ubuntu2)
libncurses5-dev (5.5-5ubuntu2)
flex (2.5.33-10build1)
For some reason lua is not linked properly for a subsequent build, so
symlink the following:
ln -s /usr/include/lua50/lauxlib.h /usr/include/lauxlib.h
ln -s /usr/include/lua50/lua.h /usr/include/lua.h
ln -s /usr/include/lua50/lualib.h /usr/include/lualib.h
Download the files under "GCC-4.1 toolchain" in the "FILES" section of:
http://www.gnuarm.com/
Untar each of the files.
Now follow these directions as root:
cd binutils-2.17
./configure --target=arm-elf \
--prefix=/usr/local/gnuarm --enable-interwork --enable-multilib
make all install
export PATH="$PATH:/usr/local/gnuarm/bin"
cd ../gcc-4.2.1
./configure --target=arm-elf \
--prefix=/usr/local/gnuarm --enable-interwork \
--enable-multilib --enable-languages="c,c++" \
--with-newlib --with-headers=../newlib-1.14.0/newlib/libc/include
make all-gcc install-gcc
** IF YOU HAVE PROBLEMS HERE, CHECK THAT "." IS LAST IN YOUR PATH IF IT IS
THERE
cd ../newlib-1.14.0
./configure --target=arm-elf \
--prefix=/usr/local/gnuarm --enable-interwork --enable-multilib
make all install
cd ../gcc-4.2.1
make all install
cd ../insight-6.5
./configure --target=arm-elf \
--prefix=/usr/local/gnuarm --enable-interwork --enable-multilib
make all install
** EXPECT THIS TO FAIL!! (we still haven't figured this one out!!)
Download the latest ethernut tarball from:
http://www.ethernut.de/en/download/index.html
As the local user:
tar xjf ethernut-4.4.0
cd ethernut-4.4.0
./configure
make
As the root user:
make install
Back as the normal user:
nutconf
That's how we got it to install on Ubuntu (feisty fawn). Again the only
two "features" we found:
~ The ethernut configurator comes up blank until you resize the window.
~ It builds MUCH faster if you use ABSOLUTE paths for the settings in the
NutConf.
This allows us to develop entirely under linux. The only thing we don't
have is the ability to program directly under linux over the SAM-ICE JTAG
device. There are sites that say you can use the Olimex USB JTAG device
with OpenOCD to program in linux. I have not attempted this. We use
VirtualBox (virtualbox.org) with Windows XP and program over USB that way.
Unfortunately VBox is limited to 11Mbps USB speed, so it is much slower
than doing this in windows. Occasionally I will flash from a windows box
via VNC just for the sheer speed.
--
Tim DeBaillie
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Ole Reinhardt
> Anyways, we have found that building with "relative paths" takes about 1-2
> minutes. However, building with "absolute paths" takes about 8 seconds!!!
> Interesting little "feature", but it makes recompiling the OS in Linux
> worth your time to get setup properly.
What do you mean with "building with relativ paths". Where do you
configure this "optio"?
Bye
Ole Reinhardt
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.
Ole Reinhardt
> I wasn't aware that either kconfig (or kbuild) used on Linux kernel
> build or KDE's KConfig has native versions running on Windows? Which one
> were you talking about, or perhaps yet another? I tried to google for
> kconfig but didn't find any good sources, perhaps you can share URL?
Indeed it does not have a "native" version, but the code shoule be
a.) portable
b.) run well in cygwin.
Cygwin is needed for the gcc / make environment anyway. Kconfig is a
modified version of dialog, which itself depends on ncurses. But ncurses
should be available for windows as well.
Bye,
Ole
Ole Reinhardt
> Are you saying that you are considering abandoning lua? are you looking
> for a new script language (like python) or a compiler (like Delphi that
> runs as freepascal on linux, or Qt)?
I don't think the configurator problems are caused by lua. So I don't
have anything (good) against lua.
kconfig for example does not neet much more than a small c program (a
modified version of dialog), some shell script, make and the needed
config files. Indeed, it depends on some more libraries lieke ncurses
for example, but ncurses should be available for cygwin as well.
Bye,
Ole
Henrik Maier
Despite being just a configurator, I believe there is another aspect of
nutconf:
It visually presents Nut/OS' structure, modularity and capabilities very
well. A user can quickly browse through the configuration tree and see what
capabilities are available with a few mouse clicks. Good in particular
because a lot of these features and configuration options are not documented
anywhere else.
It is also very nice to demonstrate the powerful architecture and
capabilities of Nut/OS to a potential new user in a visually pleasing way.
I doubt that a console based tool would have the same impact on a
potentially new user in order to evaluate whether to go with Nut/OS or
another solution.
Henrik
> -----Original Message-----
> From: Ole Reinhardt [mailto:ole.re...@embedded-it.de]
> Sent: Monday, 15 October 2007 6:33 AM
> To: Ethernut User Chat (English)
> Subject: Re: [En-Nut-Discussion] NutOS configurator
>
> Hi,
>
> > I wasn't aware that either kconfig (or kbuild) used on Linux kernel
> > build or KDE's KConfig has native versions running on Windows? Which one
> > were you talking about, or perhaps yet another? I tried to google for
> > kconfig but didn't find any good sources, perhaps you can share URL?
>
> Indeed it does not have a "native" version, but the code shoule be
>
> a.) portable
> b.) run well in cygwin.
>
> Cygwin is needed for the gcc / make environment anyway. Kconfig is a
> modified version of dialog, which itself depends on ncurses. But ncurses
> should be available for windows as well.
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Harald Kipp
> Cygwin is needed for the gcc / make environment anyway. Kconfig is a
> modified version of dialog, which itself depends on ncurses. But ncurses
> should be available for windows as well.
>
>
ncurses is probably available for Windows. But I didn't install Cygwin
on my current Windows workstation, don't want to and did not need so
far. IMO, Cygwin is a very good Linux emulator. And its X-Server is one
of the rare full blown implementations. Everything is nice as long as it
works. However, there are several things I do not like.
Cygwin forces you to install a large environment, even if you just want
to use one or two *nix tools..Updates sometimes break something. This
may happen with any software. However, Cygwin is a large package,
similar to a small Linux system. Compared to Linux, it has a small user
base and you often have to spend hours to fix your individual problem
yourself. Unless you are both, a Windows and Linux Guru, it can
sometimes drive you crazy.
The biggest problem is the incompatibility among the Cygwin DLL
versions. When I used Cygwin based programs, I typically had three of
them available. But all of them come with the same name. Windows doesn't
allow you to load two different DLLs with the same name. Thus, I had to
terminate my X-Server if I wanted to run another tool with incompatible
DLLs and vice versa.
Last not least: Did you ever try to fix a problem in the Cygwin sources
yourself? Well, I gave up early, because I had been unable to find the
related source of my installation. I'm sure, it is available, but I
simply can't find it. May be I'm too stupid. Redhat insists on
delivering all sources of the Cygwin code with your application. I'm
aware, that many (all?) Cygwin based applications ignore this, but that
doesn't mean that it is OK to do so.
The majority (all?) of WinAVR executables do not require Cygwin. YAGARTO
is completely build with MinGW. Both intentionally try to avoid Cygwin.
I do not consider applications being fully portable, if they require
emulation layers like Cygwin or MinGW. On the other hand MinGW can save
a lot of effort when porting from Linux to Windows. But I'd carefully
think about using Cygwin.
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Harald Kipp
> Unfortunately 2.8 is not available as package for Debian / Unstable.
>
Building wxWidgets from the sources is painless:
http://www.ethernut.de/en/documents/debiansage.html
(Yeah, I know I mistyped Sarge :-))
> 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.
>
Mh, I typically do not change the conf files unless I need to create a
new one for a different target. But I agree, that the initial version of
the Configurator ignored the fact, that people want to build for more
than one target configuration. On Windows we are using conf file
specific subentries in the registry, which seems to work quite well.
Frankly, I do not know right now, if and how this is done for Linux.
> 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.
>
Just to make sure that I understood: The source code package will of
course unpack into ethernut-x.x.z/, but you suggest to copy this to
nutos/ during installation.
Compared to the Windows installation the only difference is, that the
root is called nutos instead of ethernut-x.y.z/. The directory structure
is the same and this would solve some problems with the Configurator
running on Linux.
On the other hand, removing the version from the root directory name
will no more allow to keep several Nut/OS versions active on one machine.
> 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.
>
I'm almost sure, that we will never get a clear vote for one or the
other tool. The wxWidgets/Lua based solution is quite fancy and, thanks
to Lua, has a big potential (see the dynamic display of the Nut/OS
version). On the other hand, it'd be an advantage to get a second
solution just for the price of some porting efforts. You can probably
count on me, specifically when it comes to the translation of existing
config files.
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Ole Reinhardt
> ncurses is probably available for Windows. But I didn't install Cygwin
> on my current Windows workstation, don't want to and did not need so
> far. IMO, Cygwin is a very good Linux emulator. And its X-Server is one
> of the rare full blown implementations. Everything is nice as long as it
> works. However, there are several things I do not like.
Personally I never worked that much with cygwin. Like you, never more
than needed. Indeed everything up to now were only theoretical
considerations. But as far as I know at least WinAVR brings a minimal
cygwin environment with a bash and some other shell tools, right?
So I thought a standard AVR development environment would depend on
cygwin anyway. And an arm environment I thought would behave the same.
Otherwise make would be very limitid to the inbuild functionality?
> Cygwin forces you to install a large environment, even if you just want
> to use one or two *nix tools..Updates sometimes break something. This
Realy? A minimal installation is only a few hundret Kb up to some few
MB, perhaps only the cygwin dll and some shell tools.
Perhaps it's not even necessary to use Cygwin at all? Perhaps kconfig
can be build staticaly linked with Mingw as well?
> [...]
> Last not least: Did you ever try to fix a problem in the Cygwin sources
> yourself? Well, I gave up early, because I had been unable to find the
> related source of my installation. I'm sure, it is available, but I
> simply can't find it. May be I'm too stupid. Redhat insists on
> delivering all sources of the Cygwin code with your application. I'm
> aware, that many (all?) Cygwin based applications ignore this, but that
> doesn't mean that it is OK to do so.
I see your objections :-) No, I never looked into the code and up to
know never wrote a program depending on CygWin. I realy would prefer not
to use it at all if possible.
I'd realy would like to give it a try. I don't have any objections
agains the NutConf tool at all, but I search for a solution that works
for all platforms without problems. In my eyes WxWidgets is underlying a
permanent change, so it's also quite difficult to impelemt a stable code
base. Me for example I'm not able to build the NutConf code without
changes, as NutConf usese the absolut state of the art API of wxwidgets
that is not available for Debian right now. kConfig is a quite old tool
with very low dependancies.
So I did not want to start a "flamewar" but a discussion about making
either the tools more stable or finding some tools that do the job as
well or even better.
Ole Reinhardt
> root is called nutos instead of ethernut-x.y.z/. The directory structure
> is the same and this would solve some problems with the Configurator
> running on Linux.
Ok, I never had a NutOS windows installation :-) Ok, so the only
difference is the main directory name. I think it would be the best if
the main directory name does not matter at all. So everybody can name it
as he want.
Btw: you said you save the global settings in the windows registry. You
could do the same on linux with gconf. Or instead use the .NutConf file
as well. We only should avoid that the correlation of config set and
conf file name is lost if the installation path is changed.
What's about using the global config only for the "Gui" settings and
save the pathes to the tools in the config file itself? So you don't
have to match anything but can read back the whole config from one file?
> I'm almost sure, that we will never get a clear vote for one or the
> other tool. The wxWidgets/Lua based solution is quite fancy and, thanks
> to Lua, has a big potential (see the dynamic display of the Nut/OS
> version). On the other hand, it'd be an advantage to get a second
> solution just for the price of some porting efforts. You can probably
> count on me, specifically when it comes to the translation of existing
> config files.
Ok! Thanks for your cooperation. I'll try to build the basic scrips and
we'll have a look how much effort is needed to have these two
configurations available.
Right now I only see one majer thing we need to change. KConfig names
it's config values (#defines) always with CONFIG_ as prefix. So we would
need to change all defines that are configurable with NutConf to use
this naming scheme as well.
What do you think about? Perhaps we should have a phone call for such
details :-)
Bye,
Ole
Tim DeBaillie
> What do you mean with "building with relativ paths". Where do you
> configure this "optio"?
If the directory is /home/ethernut/nutos/ethernut-4.4.0 and you are
working in /home/ethernut,
nutos/ethernut-4.4.0 is a relative path (relative to where you are
working)
/home/ethernut/nutos/ethernut-4.4.0 is an absolute path
You configure this in the NutConfigurator under "settings". Using
absolute paths for the app directory, build directory, library directory,
etc, appears to be much faster than using relative paths.
Tim
--
Tim DeBaillie 812-962-9402 (voice)
Ciholas Technologies 812-962-9401 (fax)
255 S. Garvin St, Suite B deba...@ciholas.com
Evansville, IN 47713 www.ciholas.com
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Tim DeBaillie
> That's how we got it to install on Ubuntu (feisty fawn). Again the only
> two "features" we found:
> ~ The ethernut configurator comes up blank until you resize the window.
> ~ It builds MUCH faster if you use ABSOLUTE paths for the settings in the
> NutConf.
I guess I should keep my big mouth shut! The NutConfigurator does have
one other error. If you try to scroll down with the scroll bar on the
tree view, the window starts rendering improperly.
I vote that the configuator should be completely usable via command line
and that there is some graphical representation that wraps the command
line implementation.
Tim
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Alain M.
Ole Reinhardt escreveu:
>
> kconfig [...] it depends on some more libraries lieke ncurses
> for example, but ncurses should be available for cygwin as well.
I have allways seen a fairly high rejection about cygwin. Having a
config that depends on so many libs can be a problem by itself...
Alain
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Harald Kipp
> I vote that the configuator should be completely usable via command line
> and that there is some graphical representation that wraps the command
> line implementation.
>
http://www.egnite.de/pipermail/en-nut-discussion/2006-July/006770.html
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion