* Gary Maxwell <gmaxwell_at_casabi.com> [Tue, 31 Mar 2009 01:28:20 -0700]:
> Andy Lego wrote:
> >
> > I did the initial cmakifying of libcurl for CMake itself and I am
> > willing to do work to get things working for the formal libcurl
> > release. But, since I did this several times over the past years, I
am
> > only willing to do this if there will be some long term maintanance.
> In
> > other words, I would like to see the Curl community to adopt CMake
as
> a
> > build system on all platforms in addition or in replacement to the
> > current build systems. This is the only way the build system will
stay
> > up-to-date.
> >
>
> And that seems to be a common theme of this thread and its
incarnations
> over the years. Nobody in the "Curl community" has stepped up, raised
a
> hand, and taken ownership beyond the initial implementation. IMO,
that's
> the major reason that development has stalled in the past.

I use CMake for building libcurl in my project, so if Curl adopts CMake
as its secondary build system, I will surely send reports and fixes to
any problems I encounter. Consider me a sitting hand-raiser. :)

To my mind, the problem is not the lack of a bold volunteer, but rather
the lack of an up-to-date initial implementation.

By the way, we need not keep two separate build chains. It is far more
convenient to use some kind of 'cmakify' script that will parse
existing autoconf files and create CMakeLists and feature tests based
on the extracted information. This approach may require special markers
in autoconf files in order that the script could locate sections easier.

This way, (not all, but crucial) changes in autoconf buildchain will
be automatically propagated into CMake buildchain, thus reducing the
maintenance costs.

--
tetetest tetetest.