2008/10/31, Dan Fandrich wrote:

> I haven't given a lot of thought to a solution. Adding a comment in the
> file like "This file is valid only for i686-pc-linux-gnu" is just easy to do
> and would help someone trying to solve the problem on his own.

Since there seems none of us have yet thought of something 'more
automatic' it is true that initially it does not matter much if the
'canonical host' identification is provided inside a comment or given
on a preprocessor macro.

If it is provided inside a comment, the format of the line would have
to be 'fixed' and kept equal for successive releases, as a library
packager might set up some scripts to automate the job. So in the end
it would be something that people would expect to be reliable.

If provided as a preprocessor definition it could be equally scanned
with simple text tools as if it was inside a comment, but with the
added benefit that it would belong to the public API and they would
know for sure that we won't easily change its format.

Obviously if we add something to the public API, we must be real sure
that we want to do so.

> I envision
> some way to let people create two libcurl builds (e.g. 32 bit and 64 bit
> builds) and install the two curlbuild.h files next to one another and
> have the right one conditionally included at compile time.

Up to now that might be the only difference. But I'm not absolutely
sure that it will be the only one for ever long. In any case, even if
more differences arise in the future, having some form of identifying
the 'canonical host' for which the headers are built should make no
harm.

Its up to us what we want to 'suffer' now and in the feature. If we
get it wrong we will really suffer it.

> I'm not saying
> that curl should be the one to do this, but if we can do something easy
> to help administrators/packagers accomplish this, we should.

Yes of course.

Besides Tor's and Mohun Biswas's comments about this issue no one else
has said anything at all. Should we await more feedback from
administrators/packagers or should we provide something already for
7.19.1 ?

> Actually, maybe nothing new is actually needed. Would it work for a
> packager to manually rename one curlbuild.h file to curlbuild-x86_64.h
> and the other to curlbuild-x86.h and create a curlbuild.h that looks like:
>
> #ifdef __x86_64__
> #include "curlbuild-x86_64.h"
> #else
> #include "curlbuild-x86.h"
> #endif
>
> As I said, I haven't thought this all the way through, but it's probably
> worth thinking about how to make this better.

That's what I'm saying. If we have no real feedback from
administrators/packagers we don't really know what is really expected.
Even thou identifying the host for which the header is built should be
harmless. But if we do we'll have to do it for ever, more or less.

We also would have to think of the implications of exposing the
libtool generated triplet. We would 'propagate' any issue related with
this to libcurl's public headers in both cases inside a comment or as
preprocessor macro. And also definitively tying the build system to
libtool

;-)

-- 
-=[Yang]=-