Sukender wrote on Monday, March 30, 2009 11:11 AM:
>
> Good arguments, IMHO. Just wanted to add a side note: as far as I'm
> concerned, and as I already explained, I don't matter which build
> system curl/libcurl uses. I just want it to be built easily on
> platforms it runs on (and at least on platforms I use!).
>

Many on this list would consider that request to be unreasonable (and a
little bit selfish). The "platforms it runs on" includes anything with
an OS and an IP stack. Care to guess how many there are?

By example, in our case, we incorporate libcurl into a middleware
software package intended for embedded systems. One of our environments
can be described as follows:
        Build Host: Windows with Cygwin make (MSYS would do)
        Toolchain: ARM RealView Developer Suite (verion
1.2, very out of date)
        Target: ARM7 running a proprietary OS and lwip IP stack

Per the chip manufacturer, we *have* to use ARM RealView (a modified gcc
chain) and it *must* be the older version due to inline assembly hacks
written into the OS. The ARM CLib for that version is missing some key
functions, and the lwip socket implementation is likewise missing some
key definitions.

I would never expect the libcurl project to support such a host-target
configuration. Furthermore, I think it is a mistake to try and cast a
wide net and capture even more build combinations than are already
supported (or partially supported) by the project, especially if that
entails migrating to new autoconf and build tools.

Among open source projects, libcurl is not that difficult to configure
and build, IMO. If someone wants to spend time developing the next great
build scripts for libcurl, that's fine. I just don't want such efforts
to become a distraction for the mainline libcurl developers who are
trying to make the actual library better. After all, I can't remember a
customer ever complimenting me on how nice my build environment was.

Cheers,
GaryM at Casabi
Received on 2009-03-30