Re: Libcurl suggestions
Date: Tue, 9 Dec 2003 15:49:42 -0500
>There are perfectly fine URL/URI libraries already, and if there isn't one
>that suits you I'm sure you can make one pretty swiftly that will.
Yeah of course. But what I meant by "wasteful" is I would be including
libwww, which as I'm sure you know, is a rather large and robust library,
just to have one function. To me, making my users download a 1MB file for a
300byte function is wasteful.
This seems like a good idea to me I guess. However, this kind of seems
exactly like what you just told me you didn't want to add. I.e. the "why
stop at just filenames?," well, "why stop at just protocols?" Meaning I can
already tell if curl supports a protocol, curl_easy_perform will return
CURLE_UNSUPPORTED_PROTOCOL, so that functioning already exists. A function
like curl_checkproto however is designed to work directly on a URL (at least
that's what I assume since you didn't like my method because it worked on an
easy handle). Therefore, what's the difference between parsing a URL to
determine the protocol and parsing a URL to determine the filename?
Anyway, hopefully this is at least one idea you will like :) I've attached a
patch that allows the user to specify a path for ares. Instead of just
--enable-ares the user can optionally specify a path. I did this a little
different than the way you handled ares though. The way you had it was it
assumes the lib and the includes are in curlsrcdir/ares. I left it like that
if you just --enable-ares (for the sake of backwards compatibility), however
if you do --enable-ares=somedir it does somedir/include and somedir/libs.
This seemed more logical since it is the standard way of doing things, it is
how curl handles it for all other libraries, and it is the default method of
installation for ares. This patch also has the side-effect of making -lares
-Lares/directory/lib show up in curl-config --libs.
I tested it out and all worked fine for me, however it seems my system has
different versions of some of the tools installed (some of the generated
files differed in things I didn't change such as autoconf checks for gcc
options), so it is probably a good idea to test it with whatever version of
automake/autoconf you use.
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
- application/octet-stream attachment: ares-specify-path.diff