RFC: Using CMake

[Ethernut]

Hi all,

I've been looking for an autotools replacement from time to time, but
nothing caught my attraction.

Since version 2.6 CMake
http://www.cmake.org/
supports cross compiling. This looks quite promising.

autotools could do a lot of nice things. Running it on native Windows
isn't trivial and I don't want to force users to install Cygwin or MingW
just to get Nut/OS up and running.

I also don't like to add more tools than absolutely necessary, but it
looks to me, that CMake may help us a lot to create Makefiles and linker
scripts for different targets.

Any opinions? Anyone, who already used this tool, may share his experience?

Thanks,

Harald

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Uwe Bonnes]

>>>>> "Harald" == Harald Kipp <harald.kipp@...> writes:
...
    Harald> Any opinions? Anyone, who already used this tool, may share his
    Harald> experience?

I rewrote xc3sprog to use cmake and was very confident with it. But finding
external libraries without a given Findxxx.cmake script is a little
harder...

I suggest to give CMake a try.

--
Uwe Bonnes                bon@...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Alain Mouette]

For What my opinion may be worth...

Cigwin may be a PITA, but using mingw on windows is ok, I just used it
for 2 projects and it is both simple to install and well behaved.

I used it with Code::Blocks wich I loved. I will try to move from
Eclipse do Code::Blocks soon as my generica ARM platform :)

Alain

Uwe Bonnes escreveu:

>>>>>> "Harald" == Harald Kipp <harald.kipp@...> writes:
> ...
>     Harald> Any opinions? Anyone, who already used this tool, may share his
>     Harald> experience?
>
> I rewrote xc3sprog to use cmake and was very confident with it. But finding
> external libraries without a given Findxxx.cmake script is a little
> harder...
>
> I suggest to give CMake a try.
>

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[uprinz]

I don't know what you're exactly talking about...

But I was involved in a project that mixed code for the cross platform,
code for the PC and code generated by the code for the PC but compiled
for the cross platform... Ok, now you're puzzled, I know!

Example:
Project has large menus and icon-sets. But not all targets need all menu
entries and therefore not all icons. The code for the pc includes header
files defining the menus and icons. It also includes all those platform
definition header files. The same files are included by the cross
plattform.

On the compiler run, the cross toolchain compiles and links only the
menus and icons needed from the sources. Then the pc-compiler compiles
the binary generator and compressor for the menu, font and icon file.
The binary generator sped out new c and header files for the cross
platform too. That because the linker has to find the real addresses of
what is left over when the rest of the code is compiled.
Then the objectcopy tool is invoked from the Makefile and everything is
put together into the flash-image.
This handling looks awefull but it is very tricky and pretty neat. As
both toolchains are feeded with the same files, containing the same
defines and ifdefs they talk about exactly the same details.
I just disabled one menu entry and spared several hundred bytes of icons
and characters. It doesn't have a big effect on western languages, but
if you can skip some Asian characters... wow!

For NutO/S you can use this mechanism to generate a specialized font for
several displays out of one single base font, while the displays have
totally different features, byte-orders or bits per pixel information.
You can even compress the font in different manor depending on the CPU
or displays features for decompression.

It worked quite good with mingw. CygWin is to much oversized.

Best regards,
Ulrich

Harald Kipp schrieb:

> Hi all,
>
> I've been looking for an autotools replacement from time to time, but
> nothing caught my attraction.
>
> Since version 2.6 CMake
> http://www.cmake.org/
> supports cross compiling. This looks quite promising.
>
> autotools could do a lot of nice things. Running it on native Windows
> isn't trivial and I don't want to force users to install Cygwin or MingW
> just to get Nut/OS up and running.
>
> I also don't like to add more tools than absolutely necessary, but it
> looks to me, that CMake may help us a lot to create Makefiles and linker
> scripts for different targets.
>
> Any opinions? Anyone, who already used this tool, may share his experience?
>
> Thanks,
>
> Harald
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ethernut]

Hi Alain,

Alain Mouette wrote:

> Cigwin may be a PITA, but using mingw on windows is ok, I just used it
> for 2 projects and it is both simple to install and well behaved.

The problem with MingW is, that it doesn't include all tools that may be
required sometimes. Anyway, I'll try to keep the Nut/OS tools running on
native platforms. No Cygwin, no Mingw and no Fink.


> I used it with Code::Blocks wich I loved. I will try to move from
> Eclipse do Code::Blocks soon as my generica ARM platform :)

While the whole world is moving to Eclipse, it is interesting to read,
that some people move away from it.

Actually I'm not sure about wxWidgets anymore, since Nokia changed the
Qt license. Remember, that we are waiting about 2 years for wxWidgets 3
and there is not even an announcement of its release.

Harald

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Thiago A. Corrêa]

Hi,

On Tue, Sep 8, 2009 at 7:47 AM, Harald Kipp<harald.kipp@...> wrote:
>
> Actually I'm not sure about wxWidgets anymore, since Nokia changed the
> Qt license. Remember, that we are waiting about 2 years for wxWidgets 3
> and there is not even an announcement of its release.
>

Interesting you mention it *smile*. I've used Qt for years.

I've been working on a substitute to the configurator using Qt. I can
already load config files, and show the configuration tree like the
current configurator. Right now I'm missing some of the registry
settings loading/saving and the build. I would say that I'm 65% done.
I work on it from time to time, but right now it's on hold for a
little while.

Right now I'm keeping it private until I get it fully working (ie,
building Nut/OS) but I could share the code. I could even make it BSD,
since it has no link with the GPL'ed one anymore, and I don't like the
GPL so much, even if write GPL code from time to time.

Kind Regards,
    Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ethernut]

May be I should have added more details.

We are currently using GNU autoconf and automake to create a Nut/OS
source code package for Linux and OS X. The configuration files for
these tools are included in the package and are used to build the final
binaries and documents on the user's machine.

The autotools try to find out, what is available on the machine, like
compiler, wxWidgets, Doxygen etc. Depending on this environment they
will create the right Makefiles to build nutconf, the API reference etc.

One of the additional features is, that the autotools also replace the
version number in the API documents by generating the Doxygen config
file from a template. This is not available on Windows, because we don't
use any such tool on this platform. The config file needs to be updated
manually.

If such a tool would be used on all host platforms, more could be done.
During installation we may, for example, create linker scripts for
slightly different targets from the same template file. We may even
replace the number of Makedefs, Makerules etc. by a few templates.

Furthermore, CMake (or similar) can create application Makefiles, ICC,
Eclipse or Code::Blocks project files.

Last not least, you could add more fancy stuff like what Ulrich
described for converting/replacing GUI elements.

Of course, CMake (or similar) cannot do this by itself, but create the
right configurations for tools, which are able to do this.

Note, that in the first place CMake was created to automatically create
binaries from sources. As such, it fails when trying to create binaries
for other targets. As far as I understood, it can do this now since 2.6.

If you are not too familiar with autotools or CMake, let me give you an
example: It should be possible to detect the version of the newlib
automatically and then fix the unsetenv issue accordingly.

Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ethernut]

Hi Thiago,

As this might become a discussion of its own, I changed the subject.

Thiago A. Corrêa wrote:

> On Tue, Sep 8, 2009 at 7:47 AM, Harald Kipp<harald.kipp@...> wrote:
>> Actually I'm not sure about wxWidgets anymore, since Nokia changed the
>> Qt license. Remember, that we are waiting about 2 years for wxWidgets 3
>> and there is not even an announcement of its release.
>>
>
> Interesting you mention it *smile*. I've used Qt for years.

GUI programming is not trivial and the more libs you use, the more
confusing it may become. Most people involved in open source also do
closed projects. Saving the royalties for commercial projects was a plus
of wxWidgets.

From what I know so far, Qt has a native look. But does it feel native?
Another advantage of wxWidgets is, that it uses native controls, while
Qt uses generic ones. One example is the file select dialog. Unless you
use the optionally available generic wxWidgets dialog, the user will
recognize no difference, whatever platform the application runs on.

There are drawbacks as well. Controls like the nutconf module tree,
which are not available on all targets, never worked flawlessly with all
GUI libs. I saw, that Qt provides such a control.


> I've been working on a substitute to the configurator using Qt. I can
> already load config files, and show the configuration tree like the
> current configurator. Right now I'm missing some of the registry
> settings loading/saving and the build. I would say that I'm 65% done.
> I work on it from time to time, but right now it's on hold for a
> little while.

Really interesting. I planned to spend a weekend to give it a first try.
Looks like you saved me from the basic work.


> Right now I'm keeping it private until I get it fully working (ie,
> building Nut/OS) but I could share the code. I could even make it BSD,
> since it has no link with the GPL'ed one anymore, and I don't like the
> GPL so much, even if write GPL code from time to time.

Nut/OS tools are typically GPL, because they don't need to be included
into the final product. My last experience with GPL was OpenOCD and FTDI
drivers...a nightmare. On the other hand, GNU really helps in cases,
where others try to ignore licenses at all.

Anyway, the original author dictates the license. As far as code has
been taken over from the wxWidgets version, I officially agree here to
use the same code under BSDL as well. However, I stole a lot of things
from the eCos configtool, that was released under GPL. If you like, I
can try to sort this out before we officially release the code.

Harald


_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ethernut]

Ulrich Prinz wrote:
> I don't know what you're exactly talking about...

I tried to explain this in more detail in my last post on this thread.


> For NutO/S you can use this mechanism to generate a specialized font for
> several displays out of one single base font, while the displays have
> totally different features, byte-orders or bits per pixel information.
> You can even compress the font in different manor depending on the CPU
> or displays features for decompression.

Now several readers will ask themselves: "What the hell should Nut/OS do
with fonts?" The answer: "Ulrich and I are discussing about a Nut/OS GUI
for some time now."


> It worked quite good with mingw. CygWin is to much oversized.

My assumption is, that CMake runs on native Windows without the need to
install Cygwin or Mingw.

Harald

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Thiago A. Corrêa]

Hi Harald,

On Tue, Sep 8, 2009 at 8:40 AM, Harald Kipp<harald.kipp@...> wrote:

> Hi Thiago,
>
> As this might become a discussion of its own, I changed the subject.
>
> Thiago A. Corrêa wrote:
>
>> On Tue, Sep 8, 2009 at 7:47 AM, Harald Kipp<harald.kipp@...> wrote:
>>> Actually I'm not sure about wxWidgets anymore, since Nokia changed the
>>> Qt license. Remember, that we are waiting about 2 years for wxWidgets 3
>>> and there is not even an announcement of its release.
>>>
>>
>> Interesting you mention it *smile*. I've used Qt for years.
>
> GUI programming is not trivial and the more libs you use, the more
> confusing it may become. Most people involved in open source also do
> closed projects. Saving the royalties for commercial projects was a plus
> of wxWidgets.

Now that Qt is released under the LGPL, it's possible to do both open
and closed source development with it without paying.
I have a full Qt license for Windows, therefore I am not bound to any
license in this code I've wrote. I could release it in any license you
like, and even double license it.

What I don't like about the GPL is exactly that, say, I start working
in a project with someone GPL'ed. Fine, years after, I want to take
some snippets for the closed source project I'm working on, which will
bring me food to the table. I might be violating someone's rights if
I'm not 100% sure that this snipped was mine ( and therefore I have
the right to relicense it the way I choose).

There is nothing I'm getting from the old Nut Configurator except for
the common C code that handles Lua and as far as I can tell, that is
not GPL (doesn't have a header) and I haven't distributed either
source or binary yet, so not licensed :D

> From what I know so far, Qt has a native look. But does it feel native?
> Another advantage of wxWidgets is, that it uses native controls, while
> Qt uses generic ones. One example is the file select dialog. Unless you
> use the optionally available generic wxWidgets dialog, the user will
> recognize no difference, whatever platform the application runs on.

Yes, fells completely native. If I build a binary statically, you
can't tell it's Qt just by looking at it. Unlike Delphi, C++ Builder,
VB and many other stuff that I can usually spot :P
The "Open File Dialog" does use the native API. Most widgets are
abstracted at the draw level, not using native widget API from
Windows, but they do feel like native controls.
That's the major difference with wxWidgets, they are a thin wrapper
around native widget calls. I hear that they were changing with
wxUniversal or something like that to follow the way Qt does it, that
is, to abstract at the draw level.

You could download from QtSoftware a copy and check the examples,
there are tons of it.

> There are drawbacks as well. Controls like the nutconf module tree,
> which are not available on all targets, never worked flawlessly with all
> GUI libs. I saw, that Qt provides such a control.
>

Yes, Qt has QTreeView. The only problem with my implementation right
now regarding the tree visualization is the checkboxes inside the
tree. Qt doesn't have checkboxes as the tree items natively. What I
have to do is actually create delegate class that will show up the
checkboxes. Shouldn't be hard to do, but I left this cosmetic stuff
for later. I wanted to get it building first so I would show it to you
guys :)

>> I've been working on a substitute to the configurator using Qt. I can
>> already load config files, and show the configuration tree like the
>> current configurator. Right now I'm missing some of the registry
>> settings loading/saving and the build. I would say that I'm 65% done.
>> I work on it from time to time, but right now it's on hold for a
>> little while.
>
> Really interesting. I planned to spend a weekend to give it a first try.
> Looks like you saved me from the basic work.
>

You could check the Qt examples anyway. It comes with the library, and
they are very nice.

>> Right now I'm keeping it private until I get it fully working (ie,
>> building Nut/OS) but I could share the code. I could even make it BSD,
>> since it has no link with the GPL'ed one anymore, and I don't like the
>> GPL so much, even if write GPL code from time to time.
>
> Nut/OS tools are typically GPL, because they don't need to be included
> into the final product. My last experience with GPL was OpenOCD and FTDI
> drivers...a nightmare. On the other hand, GNU really helps in cases,
> where others try to ignore licenses at all.
>
> Anyway, the original author dictates the license. As far as code has
> been taken over from the wxWidgets version, I officially agree here to
> use the same code under BSDL as well. However, I stole a lot of things
> from the eCos configtool, that was released under GPL. If you like, I
> can try to sort this out before we officially release the code.
>

I think there is no need.
Firstly because I'm not reusing any of the eCos code as far as I know.
Also, I'm fine with it being GPL. I consider BSDL to be more free than
GPL but I'm not that worried about it.
If it comes to that, we could rewrite the Lua C code interface,
perhaps using C++ could make it more efficient without all the
strdups.

Kind Regards,
    Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ethernut]

Thiago A. Corrêa wrote:

> There is nothing I'm getting from the old Nut Configurator except for
> the common C code that handles Lua and as far as I can tell, that is
> not GPL (doesn't have a header) and I haven't distributed either
> source or binary yet, so not licensed :D

That had been done 99% by me without using any code from the eCos
release. Contributions had been mainly bug fixes and minor upgrades.
(Sorry for downgrading your work on this part). I think we are save with
changing the license.

Another reason for using GPL is, that it would allow to include other
valuable code. But this is not relevant right now.

So I'd also vote to go for BSDL. If it turns out later, that we want to
add some nifty GPL'ed code, we may add GPL as well, if required.


> If it comes to that, we could rewrite the Lua C code interface,
> perhaps using C++ could make it more efficient without all the
> strdups.

Beside some ugly code sequences, the reason for keeping this part in
simple C is, that compiling C++ sometime creates unforseen problems. C
is quite stable. As a last chance the user is always able to create the
nutconfigure command line tool with any lousy C compiler.

Harald

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Thiago A. Corrêa]

Hi,

On Tue, Sep 8, 2009 at 3:39 PM, Harald Kipp<harald.kipp@...> wrote:

> Thiago A. Corrêa wrote:
>
>> There is nothing I'm getting from the old Nut Configurator except for
>> the common C code that handles Lua and as far as I can tell, that is
>> not GPL (doesn't have a header) and I haven't distributed either
>> source or binary yet, so not licensed :D
>
> That had been done 99% by me without using any code from the eCos
> release. Contributions had been mainly bug fixes and minor upgrades.
> (Sorry for downgrading your work on this part). I think we are save with
> changing the license.

Then no problem.

> Another reason for using GPL is, that it would allow to include other
> valuable code. But this is not relevant right now.

Yeah, we could always double license. Anyway, I don't think there is
any code that we could want to include, at least I can't think of any
right now :)

> So I'd also vote to go for BSDL. If it turns out later, that we want to
> add some nifty GPL'ed code, we may add GPL as well, if required.
>
>
>> If it comes to that, we could rewrite the Lua C code interface,
>> perhaps using C++ could make it more efficient without all the
>> strdups.

>
> Beside some ugly code sequences, the reason for keeping this part in
> simple C is, that compiling C++ sometime creates unforseen problems. C
> is quite stable. As a last chance the user is always able to create the
> nutconfigure command line tool with any lousy C compiler.
>

The C++ compiler for host systems is much more advanced than those for
embedded. Most platforms would probably be released with gcc (Linux,
Windows - Mingw, Mac OS) and it is pretty good. Even MSVC 6.0 already
had a pretty descent compiler. The Trolltech folks always had some
issues in that regard, trying to support several different platforms
and compilers, and at around Qt 4.0 they removed a lot of the ugly
compatibility macros and internal stuff, becase compilers were deemed
much more ANSI compliant then.

Since we are not supposed to use template partial specialization, we
would be quite safe in that area if we decide to use C++.
I think using C++ could simplify and speed up that code.

Anyway, I would like to show you guys my progress, should I upload it
to svn under qnutconf (that's how I call it here)?
Or I could send it to the avr32 branch at googlecode, it's still
there, even though not used since the merge.

Kind Regards,
   Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ethernut]

Thiago A. Corrêa wrote:

> The C++ compiler for host systems is much more advanced than those for
> embedded. Most platforms would probably be released with gcc (Linux,
> Windows - Mingw, Mac OS) and it is pretty good. Even MSVC 6.0 already
> had a pretty descent compiler.

You are probably right, but I still like to have a back door, just in
case. If the command line tool uses a different technology, it will more
likely be helpful if things go wrong.


> I think using C++ could simplify and speed up that code.

I agree, that this is a good argument. As usual, the developer (you)
decides. If someone (me) wants a different solution, he can do it. There
will be no conflict in this case, both solutions can be used concurrently.


> Anyway, I would like to show you guys my progress, should I upload it
> to svn under qnutconf (that's how I call it here)?
> Or I could send it to the avr32 branch at googlecode, it's still
> there, even though not used since the merge.

Great. I'd prefer nut/tools/qnutconf in SVN trunk.

Harald

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Thiago A. Corrêa]

Hi,

    Sorry for the delay. I'm moving the files here in my local svn copy.
    In my implementation (I program under windows) I found it easier
to just have a lua folder inside my qnutconf folder, and I added the
lua files to the build, so, when I run qmake, it generates a Visual
Studio project or a Makefile containing those files.
    Should I add this lua folder to the repository? If not, then under
windows we would need to specify where lua is, say, a file config.pri
with something like LUA_PATH=/some/folder
    Does our embeeded lua differs from the original Lua? Perhaps we
could use that release to build the configurator and ditch the search
for local lua install.

Kind Regards,
    Thiago A. Correa


On Wed, Sep 9, 2009 at 5:21 AM, Harald Kipp <harald.kipp@...> wrote:

> Thiago A. Corrêa wrote:
>
>> The C++ compiler for host systems is much more advanced than those for
>> embedded. Most platforms would probably be released with gcc (Linux,
>> Windows - Mingw, Mac OS) and it is pretty good. Even MSVC 6.0 already
>> had a pretty descent compiler.
>
> You are probably right, but I still like to have a back door, just in
> case. If the command line tool uses a different technology, it will more
> likely be helpful if things go wrong.
>
>
>> I think using C++ could simplify and speed up that code.
>
> I agree, that this is a good argument. As usual, the developer (you)
> decides. If someone (me) wants a different solution, he can do it. There
> will be no conflict in this case, both solutions can be used concurrently.
>
>
>> Anyway, I would like to show you guys my progress, should I upload it
>> to svn under qnutconf (that's how I call it here)?
>> Or I could send it to the avr32 branch at googlecode, it's still
>> there, even though not used since the merge.
>
> Great. I'd prefer nut/tools/qnutconf in SVN trunk.
>
> Harald
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ethernut]

Thiago A. Corrêa wrote:

>     Should I add this lua folder to the repository? If not, then under
> windows we would need to specify where lua is, say, a file config.pri
> with something like LUA_PATH=/some/folder

Adding Lua to the repository isn't that nice really, but if it helps to
work on the sources, I'd say: Let's add it. It further guarantees, that
everything is based on the same Lua code. I also saw other projects
adding a copy of the Lua sources for this reason.

>     Does our embeeded lua differs from the original Lua? Perhaps we
> could use that release to build the configurator and ditch the search
> for local lua install.

It is amazingly equal to the original, but several files had been
modified and more modifications may be required in the future. So I'd
recommend to keep it separate.

Harald
excitedly waiting to try the Qt version. ;-)


_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Thiago A. Corrêa]

Hi,

On Fri, Sep 11, 2009 at 10:25 AM, Harald Kipp <harald.kipp@...> wrote:
>
> Adding Lua to the repository isn't that nice really, but if it helps to
> work on the sources, I'd say: Let's add it. It further guarantees, that
> everything is based on the same Lua code. I also saw other projects
> adding a copy of the Lua sources for this reason.
>

Ah, ok. Problem solved them :)
I'm ready to upload the code. I had to fix a small bug in the
repository search code, after the folder move it couldn't find the
repository anymore. It actually tries harder than NutConf does, so
should be quite resilient to moves and also makes development easy.

Now I'm just missing the BSD copyright headers to the files and I'm
done for uploading. Mean while, I just took a screenshot:
http://imagebin.org/63469
Not building yet though, but ready for sharing :)

Kind Regards,
   Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Thiago A. Corrêa]

Hi,

On Fri, Sep 11, 2009 at 10:25 AM, Harald Kipp <harald.kipp@...> wrote:
>
> Harald
> excitedly waiting to try the Qt version. ;-)
>

Uploaded.
Compile instructions are:
1 - Install Qt.
2 - cd to ethernut/nut/tools/qnutconf
3 - qmake
4 - make (or nmake if using visual studio)

You can also create visual studio projects with:
qmake -tp vc

Or using the Qt Visual Studio Integration, just open the .pro file and
it will generate a project for you.

Kind Regards,
    Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ethernut]

Thiago A. Corrêa wrote:

> Uploaded.

Cool.

> Compile instructions are:
> 1 - Install Qt.
> 2 - cd to ethernut/nut/tools/qnutconf

2.1 - Set your environment by calling qtenv.bat in the qt bin directory.

> 3 - qmake

This gives

WARNING: Failure to find: qnutconf.qrc
WARNING: Failure to find: qnutconf.qrc
c:\Qt\2009.03\qt\bin\rcc.exe: File does not exist 'qnutconf.qrc'
c:\Qt\2009.03\qt\bin\rcc.exe: File does not exist 'qnutconf.qrc'

Harald

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Thiago A. Corrêa]

Hi,

On Fri, Sep 11, 2009 at 2:23 PM, Harald Kipp <harald.kipp@...> wrote:
>
> WARNING: Failure to find: qnutconf.qrc
> WARNING: Failure to find: qnutconf.qrc
> c:\Qt\2009.03\qt\bin\rcc.exe: File does not exist 'qnutconf.qrc'
> c:\Qt\2009.03\qt\bin\rcc.exe: File does not exist 'qnutconf.qrc'
>

Fixed, forgot to add qnutconf.qrc
It's there now.

Kind Regards,
    Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ole Reinhardt-2]

Hi!

I've be remained silent on this thread as I'm not familiar with CMake at
all. I'm quite happy that I got a sligtly feasible overview on
autotools.

Anyway I think we should differ between the NutOS code itself and the
associated tools like nutconf.

The user should always be able to just use simple Makefiles to compile
his NutOS based software without the need to use any futher tools like
CMake. That's because most users will have their existing embedded
projects based on simple Makefiles. Even you won't find much embedded
software projects that will use anything else.

CMake could indeed make sense to compile The tools and to create the
documentation files etc. So everything you will just do once you
downloaded you Ethernut Software Release package.

> Furthermore, CMake (or similar) can create application Makefiles, ICC,
> Eclipse or Code::Blocks project files.

That's what I would like to avoid as it will became incompatible with
the long-established work flow of much NutOS users...

> Last not least, you could add more fancy stuff like what Ulrich
> described for converting/replacing GUI elements.

Indeed... But this issue brings me to another issue I'd like to
discuss...

How can we better support different platform in parallel using just a
single NutOS tree.

Right now I have several trees scatterd all over my harddisk. In this
case the current nutconf feature to have several configurations at the
same time works more or less for me, but could'nt we improve it a
little?

Just a simple idea:

We have several configuration templates placed in nut/conf.
A very simple solution would be to just save a copy of these templates
modified by the user accordingly to his project. But extended by the
settings the user made in the edit/settings dialog of Nutconf.

If the user places this file (his own project specific configuration) in
his project folder nutconf will always be correctly configured even if
you use several sourcetrees in parallel. Perhaps even in different
revisions.

> If you are not too familiar with autotools or CMake, let me give you an
> example: It should be possible to detect the version of the newlib
> automatically and then fix the unsetenv issue accordingly.

Btw: Autotools should be able to do the same :)

Bye,

Ole Reinhardt

--
 _____________________________________________________________
|                                                             |
| Embedded-IT                                                 |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        [phone] |
| Luisenstraße 29      Mobil:             [phone] |
| 57076 Siegen         eMail:    ole.reinhardt@... |
| Germany              Web:         http://www.embedded-it.de |
|_____________________________________________________________|

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion