Hi friends,

Please read fully before replying.

curl.h at line 80 and surrounding has a preprocessor block which takes
care of defining CURL_EXTERN symbol depending on wether other symbols
are defined or not.

Attached file old_logic.txt shows existing preprocessor block and
associated truth table with the values that CURL_EXTERN currently gets
depending on the other symbols.

I propose changing existing preprocessor block to the one shown inside
attached new_logic.txt file which also has its associated truth table
with the new values that CURL_EXTERN will get depending on the other
symbols.

Proposal modifies how CURL_EXTERN is defined for 5 out of 16 possible
cases, while retaining the other 11.

The change is motivated due to existing logic blocking the possibility
of making some curlx_* functions become true curlx_ citizens and
blocking any potential work in that direction. Notice that this change
alone is not enough to achieve mentioned purpose but it is a necessary
one. Given that this part touches curl.h and that at a first glance
this might seem as potential external API changes I'm bringing this
now in first place for others consideration.

Lets forget about curlx_* and lets focus on this curl.h specific
change I'm proposing...

Read attached files now if you haven't done yet.

I won't mention the 11 cases that don't change, except for saying that
these 11 are properly defined.

Cases [D-old] and [F-old] are only meaningful when targeting windows
or symbian. Given that for these two systems CURL_EXTERN_SYMBOL is not
defined at all, the change makes no difference for libcurl existing
users, CURL_EXTERN will actually remain defined to nothing with
existing code and proposed one. The difference is that proposed code
is formally correct while existing one is based on the assumption that
CURL_EXTERN_SYMBOL will not get defined for these systems, if someone
defines it, static library builds and its usage will both fail.

cases [1-old], [5-old] and [7-old] are meaningful when not targeting
windows or symbian, and additionally using the symbol-hiding feature
on systems/compilers that support it. When this happens CURL_EXTERN
gets defined to CURL_EXTERN_SYMBOL which is an improper definition for
these three cases. Lets see each in more detail.

Case [5-old] and [7-old] both are triggered when compiling with
CURL_STATICLIB defined making CURL_EXTERN getting defined to
CURL_EXTERN_SYMBOL. This is not good. Compiler might ignore it, warn
or simply fail when later linking generated object file.

Case [1-old] is triggered when compiling with BUILDING_LIBCURL not
defined, which is simply nonsense given that the source file is not
being used to build libcurl but CURL_EXTERN is being defined to
CURL_EXTERN_SYMBOL.

I feel my description above might not be too good, but truth tables in
both files clearly show what's going on and which is the change I
propose.

There's something else to notice...

With existing preprocessor block, having BUILDING_LIBCURL defined or
not only made a difference for windows or symbian targets. With the
proposed code having BUILDING_LIBCURL defined or not makes a
difference for all targets not only windows or symbian. So slight
adjustment of makefiles when building libcurl itself will be needed.
On the other hand it should allow simplification of other build
targets which right now use rather complicated logic to allow proper
building.

It seems to me that the change won't make any kind of impact on
libcurl users, while allowing us to advance in other build issues.
Remember that curl.h is used both by libcurl users externally, and
also by many source files while building the library.

I would actually consider this change a corner-case bugfix. But I'd
appreciate input on this proposed change before attempting to go any
further, or making a formal patch for this

Thanks,

-- 
-=[Yang]=-

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html