On Mon, Sep 05, 2005 at 12:35:38AM +0200, Daniel Stenberg wrote:
> On Sun, 4 Sep 2005, Richard Atterer wrote:
> > 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...!

Um - so far my impression is that these libs will consist almost entirely
of functions of the form
  void somefnc(args) { SSL_fnc(args); }
so I didn't think it'll get useful anytime soon.

However, I agree that other libs/programs beside libcurl will encounter the
same license issues, so the mechanism might be useful for others.

But can we make the API non-public for the first year or so after this is
first released? I'd rather not support the first ABI forever, it's bound to
have some deficiencies.

"sectra" is a bit cryptic, maybe "anyssl" is more intuitive? Well, you
decide!

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

Yes, exactly - the patch doesn't yet address this; curl-config will need to
be changed to support this kind of thing.

I'm not sure about the switches to support, though. Different people will
want different things:

- "My app is GPL. I don't care about SSL, but don't link against OpenSSL"
- "My SSL app triggers that GnuTLS bug; use OpenSSL, fail if not supported"
- "If you have GnuTLS support, give me that, otherwise OpenSSL, otherwise
   no SSL support"

To support at least the above scenarios, you could introduce a number of
different switches: --gpl-source --must-have-ssl
--with{,out}-{openssl,gnutls} etc etc.
But this would be confusing. Unfortunately, I haven't managed to come up
with a nice small set of switches yet.

> >- new switch --with-separate-libs (default: yes)
>
> 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.

Hm, I'd rather keep the default of "yes". :-/ I fear that "no" will mean
that the "monolithic libcurl" will stay the predominant distributed form,
and that Debian will become binary incompatible to the rest of the distros
due to its use of "yes".

Maybe "yes" could be made the default with --prefix=/usr ? I don't really
like this idea, but it's better than nothing. Of course, the configure
script should print a big warning that the default setting is changed.

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

I followed section "9.1.3 Conditional compilation of sources" of the
automake 1.7 docs.

But I realize I can use automake conditionals instead! I thought that the
"if SOMEFEATURE" in Makefile.am would be copied to the Makefile and make it
GNU-make-only, but this does not seem to be the case.

Cheers,

  Richard

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