Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Ralf Corsepius <rc040203 <at> freenet.de> writes:
> On Sat, 2008-10-11 at 01:20 +0200, Lennart Poettering wrote:
> > Oh, and I think that cmake is a big trainwreck.
> I share this view. Cmake is imake in new clothes and suffers from the
> same design flaws as imake did.
Like for example?
The complaints I've read about imake is that it has tables for
what
systems have what properties and that you had to maintain those. Assuming
that's true (I haven't actually used imake), that's very different from
how CMake works. CMake can do configure checks just like autoconf, the
difference is that it won't waste time on tests you didn't ask for (and
thus won't use the results of anyway), like the existence of ubiquitous
ISO C90 headers like <string.h> or ubiquitous ISO C90 functions like
memcpy and memset.
Sorry, but either you cater to all strange systems out there (autotools and
it's ilk) or target a narrow subset. The later is easier, the former
implies looking if some stuff that "normal" systems have (_of course_) are
present... can't have both.
> It's only the limited set of requirements being used by the
limited set
> of use cases it's proponents apply which lets them think "cmake is
> better".
Limiting yourself to the range of stuff really relevant is good advise...
CMake is used by all of KDE 4, and several other projects have
switched
to CMake following that example (or in some cases, because the KDE
Window$ porters did the port for them), and I'm not aware of anyone
having switched back.
Yes. But what was proposed here is switching /all/ packages using those to
cmake (or some such). Won't happen. And doing it in Fedora only is madness.
--
Dr. Horst H. von Brand User #22616
counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513