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

21 lines
464 B
Plaintext
Raw Normal View History

libnfc: new package Signed-off-by: Simon Dawson <spdawson@gmail.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-05-02 03:40:02 +02:00
config BR2_PACKAGE_LIBNFC
bool "libnfc"
libusb: needs thread support libusb needs thread support, and so do other packages that depend on it. [thomas.petazzoni@free-electrons.com: adds threads dependency to libnfc-llp, which selects libnfc.] Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-06-28 03:35:25 +02:00
depends on BR2_TOOLCHAIN_HAS_THREADS # libusb
libnfc: new package Signed-off-by: Simon Dawson <spdawson@gmail.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-05-02 03:40:02 +02:00
select BR2_PACKAGE_LIBUSB
select BR2_PACKAGE_LIBUSB_COMPAT
help
Public platform independent Near Field Communication (NFC) library.
http://www.libnfc.org/
libnfc: make example build optional [Peter: trip patch, add AUTORECONF] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-06-10 11:43:43 +02: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_LIBNFC
libnfc: make example build optional [Peter: trip patch, add AUTORECONF] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-06-10 11:43:43 +02:00
config BR2_PACKAGE_LIBNFC_EXAMPLES
bool "build libnfc examples"
select BR2_PACKAGE_READLINE
libusb: needs thread support libusb needs thread support, and so do other packages that depend on it. [thomas.petazzoni@free-electrons.com: adds threads dependency to libnfc-llp, which selects libnfc.] Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-06-28 03:35:25 +02: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
Config.in files: unify comments of toolchain option dependencies This patch lines up the comments in Config.in files that clarify which toolchain options the package depends on. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-13 16:55:32 +02:00
comment "libnfc needs a toolchain w/ threads"
libusb: needs thread support libusb needs thread support, and so do other packages that depend on it. [thomas.petazzoni@free-electrons.com: adds threads dependency to libnfc-llp, which selects libnfc.] Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-06-28 03:35:25 +02:00
depends on !BR2_TOOLCHAIN_HAS_THREADS
Reference in New Issue Copy Permalink