Hello Daniel,

Sorry to raise this question again - I just want to support Daniel
Egger's initiative.

>> Hm, could do that but I'm not sure it'll help much other than to bring the
>> ifdef hell to other applications, too. Either one uses the multi interface
>> or not. Best thing one could do with the define is to throw a better error
>> message if the API is without multi interface which is really needed.

DS> No. The libcurl API is set and fixed and we don't offer any alternative APIs.
DS> I'm all for providing configure tweaks to modify internal things but I want
DS> the line to be drawn below the API. If you want to disable things, you make
DS> the API remain but always return error.

API consistency is only needed for dynamically-loaded libraries (DLL,
.so, .dylib or whatever). For statically-linked libcurl there is
absolutely no need to retain multi-API if it is not used. Static libs
by their design cannot cause incompatibility problems for other
applications. Thus, Daniel's patch is perfectly applicable to static
libcurl builds - and it's very desired, too! (at least by me).

I propose to make CURL_DISABLE_MULTI dependent on CURL_STATIC_LIB:
dynamic libcurl? - then cannot and will not disable multi interface;
static libcurl? - ok, you have this option.

DS> Your patch as suggested introduce a whole slew of "ifdef maze" so its funny
DS> you say you dislike that! For example you could easily #define macros for
DS> functions that are no longer present in the code like:

DS> #define func(x,y)

DS> instead of:

DS> #ifdef HAVE_DISABLE_MOO
DS> func(a, b);
DS> #endif

DS> I like that since it enhances readability a lot and makes it less error-prone
DS> when people come moving around functions etc in the future.

Ok, I agree here: #defines make code simpler to read and understand.

DS> All this taken into account, I'm far from convinced this is a patch we should
DS> apply.

Daniel, please do not be so abrupt. If you are against the patch
because it is not the best example of coding style - then it's one
thing. But if you are against because the patch is "ideologically
incorrect", things differ dramatically. So, which option do you
choose? :)

For me, the idea of debloating the library is very appealing. The
patch itself may be suboptimal in terms of code clarity - but then,
the patch is to be reworked, not rejected.

-- 
Best regards,
 Tetetest                            mailto:tetetest_at_rambler.ru