On 06.10.2008, at 18:47, Dan Fandrich wrote:

> This patch is a different from all the other configure --disable
> options
> in that it changes the libcurl ABI. That has several implications, the
> largest of which is that it can't be used to make a generic library.

Indeed.

> It's only applicable to application users who will be linking
> statically or
> working in embedded devices, and those users must be fully aware of
> the implications.

True, too.

> The nature of the patch also means that having a special
> CURL_VERSION_MULTI
> check for the multi API is completely superfluous. Any application
> that
> requires the multi interface and therefore may want to check that
> flag will
> get a link error well before it can even be run. Any application
> that is
> able to link to a multi-api-free-libcurl won't need the multi
> interface
> and therefore couldn't care less about the CURL_VERSION_MULTI flag.

Indeed, but it can be used to find out the supported featureset when
running the testcases. That's why I added it.

> Given that, and the historic precedent shown with other special-case
> and seldom-used configure options, I don't think it's worth bloating
> the
> test harness with automatic checks for a multi-free libcurl.

I really wouldn't call it "bloat". The overhead is negliable and
the changes straight-forward.

>> - ifndef guards for the test library helper functions to compile
>> correctly

> Something like this is going to be necessary (unless the ABI is
> preserved--
> see below).
>
>> - addition of multi keyword and/or multi feature to testcases that
>> need
>> 'em

> There is a reference to CURL_DISABLE_MULTI in multi.h, which is
> forms part
> of the libcurl API. Since this symbol is only valid while building
> curl,
> it won't be valid for any other application that uses libcurl. It
> should
> instead be added to curlbuild.h so it's available to all apps.

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.

> On second thought, a better approach to this whole thing may be to
> replace
> all the multi functions with stubs that simply return an error
> code. That
> preserves the ABI and sidesteps many of the problems addressed here.

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

Servus,
       Daniel
Received on 2008-10-06