Hello all,

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.

This patch does _not_ actually change any code yet, it just sets up the
build environment for what we want to do.

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.)

"Separate lib" is the more official-sounding name I made up for "lib2" from
the distro-dilemma document. These libraries are "separate" because the
code they contain is not linked into libcurl.so at compile time, instead it
ends up in its own .so file.

configure.ac:

 - Try GnuTLS by default, no --enable-gnutls needed (Default for
   USE_GNUTLS is "yes", was "no".)

 - 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

 - AC_SUBST(SEPARATE_LIBS) contains a list of libs to be built
   separately. If both OpenSSL and GnuTLS are present, the value of
   SEPARATE_LIBS will be "libcurl-nossl.la libcurl-openssl.la
   libcurl-gnutls.la"

 - 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.

 - Cleanup: Related variable names all start with OPENSSL_ or GNUTLS_
   (or same in lowercase if not AC_SUBSTed)

I have tested my changes by configuring and compiling with OpenSSL and/or
GnuTLS, both with a copy of the lib(s) installed in the standard system
locations and in a non-standard dir inside my home directory. Currently,
libcurl only builds --without-separate-libs, the curl binary may fail to
link.

lib/Makefile.am:

Assorted black magic to allow the separate libs to be built conditionally,
as determined at configure time. This mostly follows the automake docs.

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.

Unfortunately, my attempt to use the undocumented variables
libcurl_openssl_la_OBJECTS etc. fails. These vars are created by automake
internally from the respective _SOURCES vars, but somehow they end up
having the wrong values for me.

Another note:

* 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". A long Internet search on this did not turn up anything
useful except for
<http://threebit.net/tutorials/apache2_modules/tut1/tutorial1.html>, but
even that does not seem to apply.

buildconf: running autoconf
configure.ac:89: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:92: error: possibly undefined macro: AC_PROG_LIBTOOL
The autoconf command failed

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer     |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯