Re: [libposix-development] Why CMake?

[Henrique A. <hd...@gm...>]

 The project doesn't aim to target most restricted environments. As a
general rule, the target platform must fully suport POSIX requirements
(at least all the mandatory parts) and such environments are usually
powerful enough to support compilers, like gcc (thus c++) and others.
I know that CMake isn't portable to some platforms, but:

 - it should be easily ported to all platforms we are targeting (ie,
full featured Unix systems)
 - even when there are no native C++ compilers for some target, a C++
application can be built with a cross compiler (the actual deployment
on the target board may be easy or hard depending on the vendor tools)

 Do you have some specific embedded target in mind ? In general,
libposix doesn't support embedded targets for the above reason. This
is regarded as a good thing, because any user of libposix can trust on
which features are available on the system (at least the mandatory
ones). Also, there are many other libc implementations that target
embedded system that can do a better job than libposix for that
purpose: they are the uclibc, newlibc, and (soon) eglibc (and we don't
try to compete with projects that already do it right, we only
complement them). See the libc comparison page, for a better
explanation when each libc implementation is better suited:

 http://sourceforge.net/apps/mediawiki/libposix/index.php?title=Compare

 Do you have an specific embedded environment in mind ? If you need a
good "insanely" stripped down libc implementation, a starting point is
Android libc. It's a stripped down FreeBSD libc ported to linux, which
aims to do only what Android tools need and nothing else. ;-)

 A note about CMake: I'm in the middle of the process of porting our
GNU Makefile to CMake. The main reason for that is code
maintainability. GNU make is too powerful and, traditionally,
makefiles become unreadable and unmantainable with time. CMake is
automatically dealing with specific platform tools, so we don't need
to deal with them most of the time.

 Said that, I must confess that I'm not overly confident with the
CMake port. It's not that CMake can't do the most usual cases
perfectly (which are compiling or cross compiling for a single
target). I'm afraid CMake doesn't have support to do the most advanced
tasks (eg: single command cross compilation to multiple targets,
deploying libraries in emulators, testing them, etc.) without custom
commands. If CMake becomes more a burden than a useful tool, then
we'll need to choose something else (eg, GNU Make).

 For short: CMake was chosen because it's accordance with the project's goals.

2009/6/24 Kirill A. Shutemov <ki...@sh...>:
> Why does the project use CMake? CMake has written in C++. C++ is not
> available on every platform(e.g. embedded). I think better way is use
> GNU Make instead of CMake to improve portability.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Libposix-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libposix-development
>



-- 
 Henrique Dante de Almeida
 hd...@gm...