Hello,

I participated in projects where that was the idea and eventually one of the
build systems "won". The logistics of maintaining two build systems are
simply too big.

As for the initial implementation, I did it twice already, since CMake is
using libcurl and it actually distributes one (though an old version by
now). I just want to make sure that if I do it again, that people will take
over and maintain it.

Andy

On Tue, Mar 31, 2009 at 6:59 AM, tetetest tetetest <tetetest_at_rambler.ru>wrote:

> * 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.
>

-- 
Lets bike the world together
http://legoandy.com