[En-Nut-Discussion] RFC: Using CMake
Ole Reinhardt
ole.reinhardt at embedded-it.de
Fri Sep 18 11:11:22 CEST 2009
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: +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 |
|_____________________________________________________________|
More information about the En-Nut-Discussion
mailing list