2008/9/4, Mohun Biswas wrote:

> Yang Tse wrote:
> > 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.
> >
>
> Thanks. I'm wondering if there might be a solution to please both sides.
> Could the stuff in curlbuild.h/curlrules.h be wrapped in ifdefs such that
> someone in my position could override the checks by simply asserting "I know
> the answers and here they are"? I.e. something like
>
> #if !defined(CURL_SIZEOF_CURL_OFF_T)
> #endif
>
> and
>
> #if !defined(CURL_SIZEOF_LONG)
> #endif

If you are certainly decided to have two binary libcurl libraries
available for development on the same machine you must provide the
developers that will be using the libraries, that you have built, the
means to use the appropriate set of libcurl header files which are
intimately linked to the libraries that you are providing.

You can achive this in several ways...

One possibility, probably the one that will make you suffer less in
the long run, is to install each set of curl header files on its own
include subdirectory. For example install the 32-bit configured
headers in "/usr/local/include/curl/*.h" and the 64-bit configured
headers in "/usr/local/include64/curl/*.h". In this way the developers
using your precompiled libraries will be able to use both versions
with just using the appropriate include and library path.

Of course, if you are providing more that two versions you can expand
on that concept...

/usr/local/include/platform1/32/curl/*.h
/usr/local/include/platform1/64/curl/*.h
/usr/local/include/platform2/32/curl/*.h
/usr/local/include/platform2/64/curl/*.h
/usr/local/include/platform3/32/curl/*.h
/usr/local/include/platform3/64/curl/*.h

The other option, that you have already mentioned, hacking the library
header files, will impose this task on you each time a new source-code
release is made public.

I personally would not recommend this second route. Whoever tried to
do this in this way would need some knowledge of the predefined
symbols that the compiler exposes and some degree of libcurl
internals.

It is true that at this moment the 'hack the headers' method seems to
be a doable task, but at some point in the feature it might be nearly
impossible to get it right.

In case you wish to take the hacking method, I'll give you some info
that might help you with libcurl's 7.19.0 header files. (For anyone
reading this in the feature, notice that this might surely not apply
for future versions).

For simplicity sake, let's assume that we are only speaking of
'merging' the headers for a 32-bit built library with the headers of a
64-bit built one.

Configure and build the 32-bit library. Save all curl/*.h files to
/curl32/include/curl and the built libraries, static and dynamic
versions, to /curl32/lib.

Do the same for the 64-bit library. Configure and build the 64-bit
library. Save all curl/*.h files to /curl64/include/curl and the built
libraries, static and dynamic versions, to /curl64/lib.

Now you can diff /curl32/include/curl and /curl64/include/curl. You
will see that for this version the only files which are different is
curlbuild.h

Good. Now you have to know which compiler predefined symbols were
available when you compiled one version and which ones were defined
when you compiled the other one. Here is where you need the knowledge
of the compiler you are using.

You can only use compiler predefined symbols to make selections
between one generated curlbuild.h file and the other one to merge
sections of them.

If you are lucky CURL_PULL_SYS_TYPES_H, CURL_PULL_STDINT_H, and
CURL_PULL_INTTYPES_H wil be equally defined on both curlbuild.h files.
If not, you will have to find out what has controlled the definition
of these.

There will be a compiler predefined symbol that rules the definition
of CURL_SIZEOF_LONG. This is the easy one. ;-)

Another compiler predefined symbol will have ruled the definition of
CURL_TYPEOF_CURL_OFF_T and its dependants.

You get the idea. You cannot depend on libcurl definitions you can
only depend on compiler predefined symbols.

If this seems complicated, which certainly is quite a mess, wait until
we do something real fancy :-) Just kidding!

Really, don't take this 'hack the headers' method route.

Use different subdirectories for each set of header files which belong
to each compiled library. Even if it might be a bit frustrating right
now, in the long run it will pay out.

HTH

-- 
-=[Yang]=-