On Mon, 6 Oct 2008, Daniel Egger wrote:

> 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.

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

> I thought about it before the implementation and while I really detest
> the ifdef maze, there're two reasons why I chose my way:
> - Less code size
> - Compiletime errors are preferred to runtime-errors in all of my work

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

#define func(x,y)

instead of:

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

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

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

-- 
  / daniel.haxx.se