NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
8033e5b87d
kumquat-buildroot/package/libcurl/Config.in

77 lines
1.4 KiB
Plaintext
Raw Normal View History

Add new packages.
2007-05-07 05:58:30 +02:00
config BR2_PACKAGE_LIBCURL
bool "libcurl"
help
package/lib*: fix wrapping of Config.in help text The check-package script when ran gives warnings on text wrapping on all of these Config files. This patch cleans up all warnings related to the text wrapping for the Config files starting with lib in the package directory. The appropriate indentation is: <tab><2 spaces><62 chars> See http://nightly.buildroot.org/#writing-rules-config-in for more information. Signed-off-by: Adam Duskett <aduskett@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-31 15:53:50 +02:00
cURL is a tool for getting files from FTP, HTTP, Gopher,
Telnet, and Dict servers, using any of the supported
protocols.
Add new packages.
2007-05-07 05:58:30 +02:00
curl: fix homepage cURL's homepage is curl.haxx.se and not curl.haxx.nu Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-11-06 11:21:34 +01:00
http://curl.haxx.se/
curl: convert to Makefile.autotools.in format, bump version
2008-12-28 14:50:53 +01:00
Config.in files: use if/endif instead of 'depends on' for main symbol In the Config.in file of package foo, it often happens that there are other symbols besides BR2_PACKAGE_FOO. Typically, these symbols only make sense when foo itself is enabled. There are two ways to express this: with depends on BR2_PACKAGE_FOO in each extra symbol, or with if BR2_PACKAGE_FOO ... endif around the entire set of extra symbols. The if/endif approach avoids the repetition of 'depends on' statements on multiple symbols, so this is clearly preferred. But even when there is only one extra symbol, if/endif is a more logical choice: - it is future-proof for when extra symbols are added - it allows to have just one strategy instead of two (less confusion) This patch modifies the Config.in files accordingly. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2013-12-20 22:31:30 +01:00
if BR2_PACKAGE_LIBCURL
curl: convert to Makefile.autotools.in format, bump version
2008-12-28 14:50:53 +01:00
config BR2_PACKAGE_CURL
bool "curl binary"
help
Install curl binary as well
Config.in files: use if/endif instead of 'depends on' for main symbol In the Config.in file of package foo, it often happens that there are other symbols besides BR2_PACKAGE_FOO. Typically, these symbols only make sense when foo itself is enabled. There are two ways to express this: with depends on BR2_PACKAGE_FOO in each extra symbol, or with if BR2_PACKAGE_FOO ... endif around the entire set of extra symbols. The if/endif approach avoids the repetition of 'depends on' statements on multiple symbols, so this is clearly preferred. But even when there is only one extra symbol, if/endif is a more logical choice: - it is future-proof for when extra symbols are added - it allows to have just one strategy instead of two (less confusion) This patch modifies the Config.in files accordingly. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2013-12-20 22:31:30 +01:00
libcurl: optional verbose strings config This patch enables a config to set --enable-verbose during the configuration of libcurl. The option is triggered by setting BR2_PACKAGE_LIBCURL_VERBOSE. Signed-off-by: Judd Meinders <judd.meinders@rockwellcollins.com> Signed-off-by: Matt Weber <matthew.weber@rockwellcollins.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-01-31 18:26:53 +01:00
config BR2_PACKAGE_LIBCURL_VERBOSE
package/libcurl: introduce options to extend/reduce feature set Libcurl is more than 250 KiB (libcurl) / 100 KiB (curl binary) in size. About 50 KiB / 15 KiB of this can be saved by disabling features/protocols that are not commonly needed: - proxy support: 15 KiB - cookies support: 10 KiB - various less common protocols: 25 KiB (libcurl) + 15 KiB (curl binary) Note that the exact amount of space saved depends on the architecture, toolchain, and other factors. Other packages that are selecting libcurl might require protocols from the 'extra' set. But, there is no clear way to find out which packages are in this situation, in particular because issues may only be visible at runtime. Note: remove the text 'enable' on the option for 'verbose strings' as that is more common in Buildroot. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> [Peter: unconditionally remove the libcurl-option to generate C code] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-02-08 22:23:11 +01:00
bool "verbose strings"
libcurl: optional verbose strings config This patch enables a config to set --enable-verbose during the configuration of libcurl. The option is triggered by setting BR2_PACKAGE_LIBCURL_VERBOSE. Signed-off-by: Judd Meinders <judd.meinders@rockwellcollins.com> Signed-off-by: Matt Weber <matthew.weber@rockwellcollins.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-01-31 18:26:53 +01:00
help
Enable verbose text strings
package/libcurl: introduce options to extend/reduce feature set Libcurl is more than 250 KiB (libcurl) / 100 KiB (curl binary) in size. About 50 KiB / 15 KiB of this can be saved by disabling features/protocols that are not commonly needed: - proxy support: 15 KiB - cookies support: 10 KiB - various less common protocols: 25 KiB (libcurl) + 15 KiB (curl binary) Note that the exact amount of space saved depends on the architecture, toolchain, and other factors. Other packages that are selecting libcurl might require protocols from the 'extra' set. But, there is no clear way to find out which packages are in this situation, in particular because issues may only be visible at runtime. Note: remove the text 'enable' on the option for 'verbose strings' as that is more common in Buildroot. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> [Peter: unconditionally remove the libcurl-option to generate C code] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-02-08 22:23:11 +01:00
config BR2_PACKAGE_LIBCURL_PROXY_SUPPORT
bool "proxy support"
default y
help
Enable proxy support.
config BR2_PACKAGE_LIBCURL_COOKIES_SUPPORT
bool "cookies support"
default y
help
Enable support for cookies.
config BR2_PACKAGE_LIBCURL_EXTRA_PROTOCOLS_FEATURES
bool "enable extra protocols and features"
default y
help
Enable the following extra protocols and features:
- LDAP / LDAPS
- POP3 / IMAP / SMTP
- Telnet
- TFTP
- RTSP
- SMB / CIFS
- DICT
- Gopher
libcurl: Allow selection of TLS package libcurl will use Instead of defaulting to OpenSSL, allow selection of package to use through a choice in libcurl's config. The default will be to select the first enabled TLS provider in the same preference order as is used now, i.e. no change from current behavior. Some of the alternative libraries have advantages over OpenSSL in certain areas. For example, gnutls has vastly superior PKCS11 support. One can use client TLS private keys by supplying a PKCS11 URI instead of a private key file name. The TLS server cert trust store can be a PKCS11 URI, e.g. configure libcurl with a ca-bundle of "pkcs11:model=p11-kit-trust". Now server certs can be stored in a software and/or hardware HSM(s). This doesn't work with OpenSSL. However, some software only supports OpenSSL for TLS or other crypto functions. So it might be necessary to enable OpenSSL for that reason. Signed-off-by: Trent Piepho <tpiepho@impinj.com> [Peter: add BR2_PACKAGE_LIBCURL_TLS_SUPPORT and use it to hide choice & comment, explitly pass --without-foo if option is not enabled, only do .pc fixup if BR2_PACKAGE_LIBCURL_OPENSSL is enabled] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-11-08 23:25:31 +01:00
choice
prompt "SSL/TLS library to use"
config BR2_PACKAGE_LIBCURL_OPENSSL
bool "OpenSSL"
depends on BR2_PACKAGE_OPENSSL
config BR2_PACKAGE_LIBCURL_GNUTLS
bool "GnuTLS"
depends on BR2_PACKAGE_GNUTLS
config BR2_PACKAGE_LIBCURL_LIBNSS
bool "NSS"
depends on BR2_PACKAGE_LIBNSS
config BR2_PACKAGE_LIBCURL_MBEDTLS
bool "mbed TLS"
depends on BR2_PACKAGE_MBEDTLS
libcurl: add wolfssl as an option for TLS Libcurl recipe allows selecting between various TLS backends. Users can already select between several options but WolfSSL was missing. WolfSSL is an efficient TLS library, it supports TLS 1.3 and is used in many embedded systems. Add WolfSSL to libcurl "SSL/TLS library to use" choice list when WolfSSL package is enabled. When selected in the list, use libcurl --with-wolfssl configure option. Explicitly set --without-wolfssl when it is not selected. Signed-off-by: Julien Grossholtz <julien.grossholtz@openest.io> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2019-11-05 11:06:59 +01:00
config BR2_PACKAGE_LIBCURL_WOLFSSL
bool "WolfSSL"
depends on BR2_PACKAGE_WOLFSSL
package/libcurl: add option for no SSL/TLS support Since we already have a choice to select the backend to do crypto, push the limits even further and add an option to do no crypto. Usually, we would have added that option first in the choice, but if we were to do that now, existing defconfigs that previously used openssl (the first item in the choice) would now default to non crypto, which is not so nice. So we add the new option last in the choice. Each crypto backend option is used in a conditional block, each of which default to disabling said backend. So, selecting none will indeed disable all. We can now drop the blind intermediate option that would hide the choice when no backend library was available; there will now always be at least the none option in the choice, so we need not hide it. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Baruch Siach <baruch@tkos.co.il> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Julien Grossholtz <julien.grossholtz@openest.io> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-12-31 17:40:23 +01:00
config BR2_PACKAGE_LIBCURL_TLS_NONE
bool "None"
libcurl: Allow selection of TLS package libcurl will use Instead of defaulting to OpenSSL, allow selection of package to use through a choice in libcurl's config. The default will be to select the first enabled TLS provider in the same preference order as is used now, i.e. no change from current behavior. Some of the alternative libraries have advantages over OpenSSL in certain areas. For example, gnutls has vastly superior PKCS11 support. One can use client TLS private keys by supplying a PKCS11 URI instead of a private key file name. The TLS server cert trust store can be a PKCS11 URI, e.g. configure libcurl with a ca-bundle of "pkcs11:model=p11-kit-trust". Now server certs can be stored in a software and/or hardware HSM(s). This doesn't work with OpenSSL. However, some software only supports OpenSSL for TLS or other crypto functions. So it might be necessary to enable OpenSSL for that reason. Signed-off-by: Trent Piepho <tpiepho@impinj.com> [Peter: add BR2_PACKAGE_LIBCURL_TLS_SUPPORT and use it to hide choice & comment, explitly pass --without-foo if option is not enabled, only do .pc fixup if BR2_PACKAGE_LIBCURL_OPENSSL is enabled] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-11-08 23:25:31 +01:00
package/libcurl: add option for no SSL/TLS support Since we already have a choice to select the backend to do crypto, push the limits even further and add an option to do no crypto. Usually, we would have added that option first in the choice, but if we were to do that now, existing defconfigs that previously used openssl (the first item in the choice) would now default to non crypto, which is not so nice. So we add the new option last in the choice. Each crypto backend option is used in a conditional block, each of which default to disabling said backend. So, selecting none will indeed disable all. We can now drop the blind intermediate option that would hide the choice when no backend library was available; there will now always be at least the none option in the choice, so we need not hide it. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Baruch Siach <baruch@tkos.co.il> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Julien Grossholtz <julien.grossholtz@openest.io> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-12-31 17:40:23 +01:00
endchoice
libcurl: Allow selection of TLS package libcurl will use Instead of defaulting to OpenSSL, allow selection of package to use through a choice in libcurl's config. The default will be to select the first enabled TLS provider in the same preference order as is used now, i.e. no change from current behavior. Some of the alternative libraries have advantages over OpenSSL in certain areas. For example, gnutls has vastly superior PKCS11 support. One can use client TLS private keys by supplying a PKCS11 URI instead of a private key file name. The TLS server cert trust store can be a PKCS11 URI, e.g. configure libcurl with a ca-bundle of "pkcs11:model=p11-kit-trust". Now server certs can be stored in a software and/or hardware HSM(s). This doesn't work with OpenSSL. However, some software only supports OpenSSL for TLS or other crypto functions. So it might be necessary to enable OpenSSL for that reason. Signed-off-by: Trent Piepho <tpiepho@impinj.com> [Peter: add BR2_PACKAGE_LIBCURL_TLS_SUPPORT and use it to hide choice & comment, explitly pass --without-foo if option is not enabled, only do .pc fixup if BR2_PACKAGE_LIBCURL_OPENSSL is enabled] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-11-08 23:25:31 +01:00
Config.in files: use if/endif instead of 'depends on' for main symbol In the Config.in file of package foo, it often happens that there are other symbols besides BR2_PACKAGE_FOO. Typically, these symbols only make sense when foo itself is enabled. There are two ways to express this: with depends on BR2_PACKAGE_FOO in each extra symbol, or with if BR2_PACKAGE_FOO ... endif around the entire set of extra symbols. The if/endif approach avoids the repetition of 'depends on' statements on multiple symbols, so this is clearly preferred. But even when there is only one extra symbol, if/endif is a more logical choice: - it is future-proof for when extra symbols are added - it allows to have just one strategy instead of two (less confusion) This patch modifies the Config.in files accordingly. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2013-12-20 22:31:30 +01:00
endif
Reference in New Issue Copy Permalink