curl-library
Re: design problem with CURL_SIZEOF_LONG in 7.19.0
Date: Thu, 4 Sep 2008 19:00:56 +0200
2008/9/4, Mohun Biswas wrote:
> [...] Since
> our application uses a large number of libraries on a large number of
> platforms, our practice has been to keep only a single set of header files
> while building out the binary libraries per platform. Thus we have N copies
> of libcurl.so for N platforms but only a single copy of curl/*.h.
Now each configured and built libcurl.so has its own set of headers
which must be distributed and match the built library. It is true that
on nearly all platforms you can not use 32-bit libcurl headers for a
64-bit built libcurl library, as well as the contrary.
The concept of a single copy of curl/*.h for _any_ libcurl library no
longer holds true.
> With the addition of curlbuild.h and curlrules.h, the curl/*.h files now
> document not only an API but also the details of how libcurl was built on
> one particular system.
Yes. Details, which the user of the library needs to be capable of
properly using it.
> This means we must keep a copy of curl/*.h for every
> compilation environment, which seems to me a significant step backward in
> both elegance and utility.
As long as the 'compilation environments' are compatible the
configured curl/*.h will be identical. You might not have so many
'compilation environments' as you think, but surely there is one for
32-bit libcurl and another one for 64-bit libcurl.
This might impose some additional work, simply bundling the configured
headers with the built library, for the binary library distributor.
But the library user will be more happy if he doesn't get unexpected
sigsegv's due to not being able to properly interface the library.
-- -=[Yang]=-Received on 2008-09-04