[Zlib-devel] zlib 1.2.4.2 ready for its close up
Cosmin Truta
cosmin at cs.toronto.edu
Sat Apr 10 15:55:03 EDT 2010
On Sat, Apr 10, 2010 at 3:20 PM, Alon Bar-Lev wrote:
> CMake is much too much dependency for simple component such as zlib...
> Especially for embedded.
> It also has circular dependency... It depends on zlib :)
> Also, the cmake progresses too slowly, just look at the bug database
> [1] and resolve ratio.
> Have you tried cross compile the zlib using cmake? I just tried so and failed.
>
> [1] http://public.kitware.com/Bug/my_view_page.php
Alon, I don't want to start a flame war. In all honesty, the autotools
are much more mature than cmake, so chances to run into trouble with
the autotools are lesser and lesser these days, and the same cannot
yet be said about cmake, which is still a young product. Besides,
cmake isn't any more user-friendly than the autotools, as you need to
know magic incantations for both. Last but not least, cmake may be
big, and a hassle to some people, but the autotools' dependency on the
Bourne shell on my non-Unix machine is not a lesser hassle.
(Admittedly, the Unix users don't have this issue.)
I just wanted to challenge your initial point: we are using a truly
multi-platform solution (it's just not your favorite one). In
addition, in *my* opinion, the autotools are not such a great
alternative to the configure/makefile scripts that we're already
having.
For example, someone submitted an autotools solution to the libpng
mailing list, which we embraced, as a replacement of a homegrown list
of makefiles, in the hope that it will be a timesaver (e.g. useful
when a new platform comes up). Unfortunately, issues and headaches
occured afterwards, and not so much expertise was available. It turned
out that autotools was not the time saver that it purported to be,
neither development-wise nor user-wise. On the contrary: I personally
still use libpng's old handwritten makefile, because it runs much
_faster_ than the autotools-generated configure+make.
Best regards,
Cosmin
More information about the Zlib-devel
mailing list