[En-Nut-Discussion] RFC: Using CMake
Harald Kipp
harald.kipp at egnite.de
Tue Sep 8 13:15:31 CEST 2009
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
More information about the En-Nut-Discussion
mailing list