[En-Nut-Discussion] NutCOnf/Qt
Thiago A. Corrêa
thiago.correa at gmail.com
Tue Sep 8 21:36:38 CEST 2009
Hi,
On Tue, Sep 8, 2009 at 3:39 PM, Harald Kipp<harald.kipp at egnite.de> 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
More information about the En-Nut-Discussion
mailing list