Daniel Stenberg wrote:

> On Tue, 24 Aug 2004, Todd Fisher wrote:
>
>>> When is this useful?
>>
>>
>> The idea is very useful for people that use Makefiles, specifically
>> with GNU Make, cygwin makes this possible in win32 hence the ability
>> to use cl with a gnu makefile. Mozilla does this for example.
>
>
> How will you figure out what libs you need to link with libcurl? How
> can you figure out if you build libcurl with MSVC to use libz or not?
> To use openssl or not?
>
> You would need to make a curl-config for MSVC that assumes a whole lot
> and thus will fail for those that doesn't do exactly like the majority
> does, since you cannot have the curl-config generated according to the
> choices set at build time, as it is on configure-based installs.
>
>> I can see that since curl-config is generated by running the
>> configure script this type of logic would not be needed in the
>> curl-config script.
>
>
> Right, the logic is in configure, the results are in the curl-config
> script.
>
>> However, that limits the compiled libraries to only being used by the
>> said compiler.
>
>
> I don't understand this remark.
>
>> However, if curl-config checked the environment and returned the
>> correct flags for either gcc or cl then this could be more flexible.
>
>
> How would it check the environment? If you run windows, you have a
> large amount of compilers available. You can have several ones
> installed. How can the script know what compiler you want to use? The
> script would need one (or more) special command line option that would
> return info for the specific compiler you want to use.
>
> Then, how can the script tell you what libs you need to link with in
> order to make a fine build? Your patch assumed "libcurl.lib gdi32.lib
> libz.lib". What if the lib was built with SSL support? Then it needs
> two more libs. What if the lib was built without zlib support? Then
> the libz lib shouldn't be there...
>
>> Since, I can generate .lib's and .a's for both compilers why not have
>> a single curl-config that works with both too.
>
>
> "both" ?
>
>> I agree with your point that most windows people don't use the
>> command line,
>
>
> That is not quite my point. Many people use the command line on
> windows, especially when building libcurl from source. But I doubt
> even a very small fraction of those people would even consider running
> a shell script to figure out the link options to use when linking with
> libcurl.
>
> Only people using cygwin would do that. And cygwin already supports
> the configure-style build which makes the whole argument moot.
>
>> does that really mean it should just be ignored entirely?
>
>
> No. If you can provide a curl-config file that *works* on windows,
> then I won't reject the idea. Hard-coding the output from curl-config
> is just not a solution I like.
>
>> Perhaps, just adding support in libcurl for a libcurl.pc file would
>> solve this issue for me.
>
>
> It might. I know very little of pkg-config and I have very little
> experience from it so I'm not able to discuss details at this point.
>
You could have a file named libcurl.pc.in that would look something like
the following:

prefix=@prefix@
exec_prefix=@exec_prefix@
libdir=@libdir@
includedir=@includedir@

Name: Libcurl
Description:
Version: @VERSION@
Requires:
Libs: -L_at_libdir@ -lcurl @LDFLAGS@ @LIBS@
Cflags: "-I_at_includedir@"

The Requires: field can be used to tell pkg-config about the other
packages this package requires. So, for libglade
that line looks like:
Requires: gtk+-2.0 libxml-2.0

This provides a standard way of detecting the presense of libcurl on a
installed system in a user of libcurl's configure
script they can write:

AC_PATH_PROG(PKG_CONFIG, pkg-config, no)
PKG_CHECK_MODULES(MYPKG, [libcurl >= required_version_number]
AC_SUBST(MYPKG_LIBS)
AC_SUBST(MYPKG_CFLAGS)

The nice thing about this is that with the pactch I made to pkg-config
if the user has CC=cl in their environment
then when they run the configure script pkg-config will return msvc
style c libs/cflags even though they are listed in
the .pc file as gcc style. So, so long as the package supplies both
.libs and .a's then this will work. This will usually,
be the case when a library is compiled with mingw compilier.
Getting back to pkg-config, there are two things I can see are missing
for pkg-config that the curl-config provides:
1. the features option in curl-config is nice and not provided as far as
I can tell in pkg-config
2. A string would have to be supplied for Requires: which might be
difficult to determine since I believe required packages
    implies they are also using pkg-config.

I still thinking adding pkg-config support to libcurl would be nice and
I'm sure that people would jump who are more
knowledgable of pkg-config would help contribute to make it more robust.

-todd
Received on 2004-08-25