curl-library
Re: Version info in curl.h (was Re: Companies Using curl)
From: Eduardo García <garedagmad_at_telefonica.net>
Date: Tue, 09 Mar 2004 17:05:30 +0100
At 15:41 09/03/2004, you wrote:
I am very sorry for so fast answer without having tested it before.
I fear I must go back: after testing this solution, it doesn't work. The project always rebuilds. Looking deeper in compiler logs we have noticed that it cannot find "support/supportDefs.h" (build warning PRJ0041), which is only included in curl.h if _BEOS is defined !!!.... and looking why this include is then taken in account we get quite surprised with this Microsoft documentation (I am copying and pasting):
<<<
Visual C++ Concepts: Building a C/C++ Program
A file (resource file or .idl/.odl file, for example, contained an include statement that the project system could not resolve.
Because the project system does not process preprocessor statements (#if, for example), the offending statement may not actually be part of the build.
To resolve this warning, delete all unnecessary code in .rc files or add placeholder files of the appropriate name.
>>>
As you can read, #ifdefs are not processed, so our solution based on #defines will never work.
The only solutions then is keeping version defines "geographically" isolated from rest of curl.h stuff at .rc point of view.
So we chose #3 or #5 of your suggestion.
It has no sense to duplicate defines to an extra header if only .rc includes it, from my point of view. Better duplicating them in .rc directly if you don't want to create the extra header.
I understand from what you wrote that this defines are automatically created for each release, so there is no danger in getting different values for each define, is there ?
Eduardo García.
Received on 2004-03-09
Date: Tue, 09 Mar 2004 17:05:30 +0100
At 15:41 09/03/2004, you wrote:
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
I don't like duplicates. I thinks #2 is useful for windows developers like us and have the less impact in libcurl code struct.
I am very sorry for so fast answer without having tested it before.
I fear I must go back: after testing this solution, it doesn't work. The project always rebuilds. Looking deeper in compiler logs we have noticed that it cannot find "support/supportDefs.h" (build warning PRJ0041), which is only included in curl.h if _BEOS is defined !!!.... and looking why this include is then taken in account we get quite surprised with this Microsoft documentation (I am copying and pasting):
<<<
Visual C++ Concepts: Building a C/C++ Program
Project Build Warning PRJ0041
Cannot find missing dependency 'dependency' for file 'file'. Your project may still build, but may continue to appear out of date until this file is found.A file (resource file or .idl/.odl file, for example, contained an include statement that the project system could not resolve.
Because the project system does not process preprocessor statements (#if, for example), the offending statement may not actually be part of the build.
To resolve this warning, delete all unnecessary code in .rc files or add placeholder files of the appropriate name.
>>>
As you can read, #ifdefs are not processed, so our solution based on #defines will never work.
The only solutions then is keeping version defines "geographically" isolated from rest of curl.h stuff at .rc point of view.
So we chose #3 or #5 of your suggestion.
It has no sense to duplicate defines to an extra header if only .rc includes it, from my point of view. Better duplicating them in .rc directly if you don't want to create the extra header.
I understand from what you wrote that this defines are automatically created for each release, so there is no danger in getting different values for each define, is there ?
Eduardo García.
Received on 2004-03-09