On Sun, 4 Sep 2005, Richard Atterer wrote:

> the attached patch is my first go at supporting the "lib2" approach
> described in <http://curl.haxx.se/legal/distro-dilemma.html>. This doesn't
> yet do anything useful, but I'm posting it to ask people (in particular
> Daniel;) whether they agree that this is the right way to do it.

I agree to the general approach, as far as I've understood it! ;-)

> There is now provision to optionally build three separate libs called
> libcurl-nossl.la
> libcurl-openssl.la
> libcurl-gnutls.la
> (I'm open to suggestions for different names.)

I want to have it named separately from "libcurl" to make it very clear that
it isn't libcurl, but a lib that libcurl would use. Possibly "libsectra" for
Secure Transport/Transfer.

This lib would also get its own set of API/headers etc and there is a risk
that it will start living its own life if it becomes good...!

> - Do not include compiler switches specific to an SSL lib in the
> global make variables. Whereas previously e.g. "-lssl" was added to
> $LIBS in the configure script, now it is added to OPENSSL_LIBS. The
> following variables exist and are AC_SUBSTed: OPENSSL_LDFLAGS
> OPENSSL_CFLAGS OPENSSL_LIBS GNUTLS_LDFLAGS GNUTLS_CFLAGS

But how would a regular app get the options needed to link with libcurl and
lib2? I guess it would need to specify which lib2 with curl-config and get
the options for that specificly?

> - new switch --with-separate-libs (default: yes) controls contents of
> SEPARATE_LIBS. You can actually supply a space-separated list of
> lib names (e.g. --with-separate-libs='nossl openssl'), but that
> feature shouldn't really be used with the SSL libs, because as soon
> as more one lib out of "nossl openssl gnutls" is built separately,
> _all_ of the others must also be built separately.

I think it makes sense to have this default set to no to start with. I suspect
that most people who build libcurl from source won't be interested in this
extra layer of complexity.

> lib/Makefile.inc:
>
> The sources need to be split according to which libcurl-ssl*.la they end up
> in. Unfortunately, I did not find a way to avoid that you also have to
> specify a list of object files for each separate lib. Not sure yet whether
> ".lo" or ".$(OBJEXT)" (i.e. ".o") is the right extension. The automake docs
> list the latter, but then automake warns about the ".o" being non-portable.

I don't see why you need to resort to object files, but then I didn't try this
magic myself (yet). Why doesn't just adding up the source files for each lib
work?

> * The CVS configure.ac (or another auto* file) fails with libtool 1.6, I
> had to downgreade to 1.4 or 1.5. With 1.6, you get the following error
> during "autoconf".

Sigh. Ok, thanks for pointing this out. Seems I'll get myself a fun project to
fix this then! :-/

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html