>> I don't think multi.h is supposed to include curl.h, as it does today.
>> curl.h includes multi.h (at the end of curl.h). And I presume any program
>> using libcurl is supposed to include curl/curl.h and nothing else
>> explicitly.
>
>I think you're right, but I still hesitate to do the change since if someone
>(against all odds) are including multi.h already, us removing that #include
>will break a build.
>
>Or are you seeing any particular downsides or breakage by simply leaving the
>#include in there, even though it pure technically doesn't belong?

I noticed it only because I had a bug in one of the header files and the
unexpected sequence of inclusion impeded my tracking it down.

Might I suggest you add a comment explaining that the #include of
curl.h in multi.h is only for backward compatibilty? Otherwise, it is
going to make other people working on this code get the wrong idea
about the licurl header file strategy. (Because the opposite of what
libcurl does, where the user includes header files only for the facilities
his program uses, and each of those includes whatever it depends upon,
is used by some other libraries). It took me some investigation to
figure out that that one #include is anomolous.

-- 
Bryan Henderson                                    Phone 408-621-2000
San Jose, California