Daniel Stenberg wrote:
> On Thu, 4 Sep 2008, Mohun Biswas wrote:
>
>> I must admit that I haven't followed all the discussion of the
>> curl_off_t/LFS work for 7.19.0; I figured as long as the result was a
>> working library with LFS capabilities I'd be happy.
>
> If only the world was that simple. Clearly you weren't happy with _only_
> this, as apart from the bug you mention this is what you got... ;-)

True. In fact I am pretty happy :-) though there are degrees ...

>> This appears to be because the new design depends on the installation
>> of a header "curlbuild.h" with the unitary definition:
>>
>> #define CURL_SIZEOF_LONG 4
>
> Not exactly. On Solaris you run ./configure and that is then supposed to
> replace your include/curl/curlbuild.h file with one where these
> variables have been set to the sizes and types configure found.

I believe we're saying the same thing here. It's not that configure got
it "wrong", it's that it can't possibly get it right for both
environments. But it did do the right thing for some definition of right.

> Doesn't this work for you? Or did you run configure for the 32bit case
> and then built for the 64bit case without rerunning configure?

I built the 32-bit libcurl and installed the headers and library. Then I
built the 64-bit libcurl and installed only the library. This has always
worked before, for libcurl and the other open-source libraries we use,
but this time it didn't for reasons which are now understood.

> Well yes now you need to build and install both the lib and the
> associated headers in its own prefixes:
>
> ./configure --prefix=/lib/for/one-build --options-for-one
> make
> make install
>
> make clean
> ./configure --prefix=/lib/for/second-build --options-for-second
> make
> make install
>
> I do see how this is not properly document atm, but apart from the
> surprise you get and the fact that you need to get used to this idea, I
> don't think there a lot of harm in this. Previously, we had a situation
> where it was very easy to make mistakes since the headers and libraries
> required the app to know about things that the current approach tries to
> take care and inform about in its public headers.
>
> Or does it harm your use and your application any more than what I've
> tried to sum up?

Well ... I don't want to make this about me, and in particular about me
complaining. I'm very happy with libcurl in general and I can work
around this problem. More abstractly, though, this doesn't feel like an
improvement to me and I wanted to have a conversation about whether it
really is.

In the interest of completeness I'll answer your question: it does harm
my use in a couple of ways, though none deadly:

1. Our build structure is designed around having a single -I flag for libs:

        -I/third/party/libraries

and now I'll have to stick in an additional flag specifically for
libcurl headers because they move around per platform. Doable,
certainly, but less elegant.

2. It may seem that passing --prefix followed by "make install" is no
big deal but that illustrates what I consider the limited vision of
one-install-per-system. For a person with a Linux box who wants to
install to a local filesystem, that's fine. But because we're producing
production software across multiple build systems, we don't do it that
way. Instead, we keep our libraries and other build artifacts under
version control.

This works quite well, prevents skew, and actually makes upgrades easier
because once a new version is checked in it's available on all build
hosts at once. The cost is that we can't just run "make install"; we
have to 'install' the new files to the version control system manually.
This normally isn't a big deal, but managing a roster of (currently) 10
curl/*.h files across ~8 platforms plus additional compilation
environments like Solaris 32/64 approaches the pain threshold.

Actually the problem isn't pain per se but correctness. The set of files
in curl/*.h changes from release to release; IIRC this upgrade (from
7.16.x) involved adding 4 new files and subtracting an old one
(curlx.h). Doing this manually across many platforms raises the risk
that something will be overlooked and we'll be building with the wrong
set of headers on some platform for a while before someone tracks down
the bug.

So - that's my summary of the downside. But as noted, having not really
followed the discussion of the problem nor the solution I have no
standing to complain. If you who do understand it continue to feel this
is the best or only solution, I will turn my attention to making things
work smoothly here.

Thanks for reading,
MB
Received on 2008-09-04