On Mon, 5 Sep 2005, Richard Atterer wrote:

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

Well, when you check out the ssluse.c and gtls.c sources closer, you'll soon
realize that they will be somewhat more complex than so, at least for some of
the functions...

Not that I think the complexity matters, we still need to set an API/ABI for
them, be it documented or implied. We can of course document the functions as
we proceed.

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

I agree. We should treat it as a libcurl-specific library at least until we
have had it tested in multiple environments for some time.

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

Well 'curl' is not meant to be informative, and I don't think this new name
needs to be informative either. It is a name on a lib libcurl will use for
secure transport. I wouldn't mind 'anyssl' either. (I didn't include SSL in
the name, since strictly speaking it will be used for TLS as well...)

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

I think we can start with having --cflags and --libs etc work with the default
lib2 selection and have --lib2-[SSL lib] as an extra option that would force
the curl-config output to be adjusted for that lib2 version.

Having the curl-config know things like GPL vs BSD license conditions seems a
little bit too far away from what its there for, for my taste.

But sure, we can work out a lot of functionality before this needs to work.
And possibly we can get some further input and ideas from others as well.

>> I think it makes sense to have this default set to no to start with.
>
> 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".

Why would this make libcurl binary incompatible? If distro A ships with a
"monolithic" libcurl it will simply provide SSL powers using a lib2 version
built-in, while distro B that ships with separated lib2 libraries will have
them separated.

I can't see many differences from most users' view. The main (only?)
difference would be that applications on distro A can't select any other lib2
than what the distro maker decided to provide built-in.

Since applications don't use any symbols exported from lib2, they should be
able to run on systems where libcurl provides all this magic on its own. Or am
I wrong?

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

Nah, having it depend on the --prefix would be very strange and will only
surprise users.

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

No, the if lines are converted to "real" makefiles at configure time so the
generated makefiles no longer contain any ifs.

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