On Tue, 9 Mar 2004, Eduardo García wrote:

Thanks for the additional info on this!

> >True, but it would add an extra header file for no apparent reason.
>
> Perhaps some kind of #ifdef isolating these defines from the rest of the
> code would also work (#define CURLVERSION_DEFS in .rc before curl.h include
> and exclude rest of curl.h if defined), avoiding to separate an extra header
> file.

That would of course also work...

I could also have those defines get added in the libcurl.rc file as well.
They are replaced in curl/curl.h by the 'maketgz' script that makes release
ardhives, and it would be very simple to have it generate the same setup in
lib/libcurl.rc as well. It would only cause a minor nuisance for those who
build from CVS since it doesn't update that file then...

Would that satisfy you/cause problems to anyone? Of course I could also in a
similar manner produce a curl/curlver.h header too with the version
information duplicated.

> Nevertheless, what are these defines there for?

They are intended to be available for applications that want to know what
version of libcurl that is installed (or at least for what version the headers
are for).

> are they used in any other part of the code ?

lib/version.c uses them to provide a version number, but otherwise they are
primarily meant for "external" use.

> You are the the master for the project. It is your decision ;-)

Well yes, but this is an area I'm seldom visiting so I'm thankful for your
thoughts and feedback on this.

So, I counted to five different alternatives. Let's have a quick poll on the
list. What do you prefer?

1. do nothing about this

2. #ifndef CURLVERSION_DEFS_ONLY in curl/curl.h

3. lib/libcurl.rc duplicated defines

4. curl/curlver.h with duplicated defines

5. curl/curlver.h with defines, included from curl/curl.h

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]