From: Trent Piepho <tpiepho@impinj.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] libcurl: Allow selection of TLS package libcurl will use
Date: Thu, 8 Nov 2018 21:55:45 +0000 [thread overview]
Message-ID: <1541714144.30311.360.camel@impinj.com> (raw)
In-Reply-To: <87ftwb8db7.fsf@dell.be.48ers.dk>
On Thu, 2018-11-08 at 22:33 +0100, Peter Korsgaard wrote:
> > > > > > "Trent" == Trent Piepho <tpiepho@impinj.com> writes:
>
> > +choice
> > + prompt "SSL/TLS library to use"
> > + default BR2_PACKAGE_LIBCURL_OPENSSL if BR2_PACKAGE_OPENSSL
> > + default BR2_PACKAGE_LIBCURL_GNUTLS if BR2_PACKAGE_GNUTLS
> > + default BR2_PACKAGE_LIBCURL_LIBNSS if BR2_PACKAGE_LIBNSS
> > + default BR2_PACKAGE_LIBCURL_MBEDTLS if BR2_PACKAGE_MBEDTLS
>
> kconfig defaults to the first available option, so these default .. if
> .. can be removed.
I thought I had to do this, but it's been a while since I made this
patch. I'll remove them.
>
> > +
> > +config BR2_PACKAGE_LIBCURL_NOSSL
> > + bool "No SSL/TLS support"
>
> Is there really a use case for building curl without TLS support if one
> or more of the libraries are available? If not, then I would simply make
> the choice depend on openssl || gnutls || libnss || mbedtls and drop
> this nossl option.
I can't think of one besides minimizing the size of libcurl. Though I
expect someone after that level of optimization would have already
turned off all TLS libraries and they don't need this option either.
It just seemed to cover all the bases consistently. I think kconfig
doesn't like it if the choice has no options selected?
Perhaps I should change this last one to a comment "no tls" stanza,
enabled when no tls support is present, that explains one needs a tls
library.
prev parent reply other threads:[~2018-11-08 21:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-08 0:12 [Buildroot] [PATCH] libcurl: Allow selection of TLS package libcurl will use Trent Piepho
2018-11-08 21:33 ` Peter Korsgaard
2018-11-08 21:55 ` Trent Piepho [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1541714144.30311.360.camel@impinj.com \
--to=tpiepho@impinj.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox