On Sun, 24 Sep 2006, Bernard Leak wrote:

> following my usual custom, I have sworn interminably over curl's attempts
> (in 'configure') to determine curl_off_t. Is it just me, or is this really
> a persistently fragile part of the configuration?

It is just you. Otherwise I'm sure you would've told us some explanations or
details on why you claim this.

> Also, as before, I find the inclusion paths broken when the build and source
> directories are not the same.

When you do what? We frequently build curl and libcurl outside of the source
dir (as well as inside it) on a large amount of platforms without any
problems.

> And it turns out that --with-gssapi-libs doesn't work either.

Aha! I committed your patch for that, thanks!

> There are two distinct (and NOT equivalent) files called setup.h
> (lib/setup.h and source/setup.h), each of which #include s config.h . The
> assumption seems to be that this will always be in the same directory as
> setup.h, and picked up from there.

Correct.

> However, config.h (both of them) are generated files, and if they aren't in
> the source directory then they are searched for by way of the search path -
> and that is unlikely to be correct for *both* possible locations for
> setup.h, from *all* the places where they can be included.

Why? lib sources would only include the lib version and the src sources would
only include the src version. They are separate "entities" and should have
these things separate.

> That is, not only is it presently broken, but it's not clear that it can be
> trivially un-broken.

Can you please elaborate on why this is broken? Again, we can build curl and
libcurl on a very wide range of platforms both inside and outside of the
source directory. In my book, that's not entirely broken at least.

> Bear in mind that lib/setup.h is included from headers which are themselves
> sometimes included from src/somewhere.c.

Yeah true, that's a bit messy and not so beautiful, but still not a very big
deal imho. The clean way is to duplicate the code and not use any source code
at all from the lib for the command line app, and perhaps one day we'll do
that but... and still, that is only messy for the src (curl tool code) and not
for the library source code.

> And no, the two config.h files are not equivalent.

If they differ, there's a mistake done somewhere since they are meant to be
identical (the config.h.in file is copied from lib/config.h.in to src/ in
buildconf). The 7.15.5 release has a bug in exactly that department that is
since fixed.

> A half-hearted attempt has been made to solve the problem by adding
> -I$(builddir)/../src (so at least src/config.h will be found), though no
> corresponding effort has been made for -I$(builddir)/../lib.

Sorry, but I fail to see what problem your sepbuild-1.patch tries to address.

> config.h is ONLY included via setup.h, and the Right Thing might well
> be to re-name one or both of them, or to unite them as lib/config.h .

I don't really see the need for any of these options. In which case is it not
clear which setup.h that is being included?

> Is there any chance of a 'proper' version which will find the MIT krb5
> gssapi library under its own name (libgssapi_krb5.whatever) without
> requiring link fakery?

If you would explain what that means then perhaps there would be a "chance"
for that.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html