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

22 lines
578 B
Plaintext
Raw Normal View History

libnspr: Add dependency on !BR2_xtensa and !BR2_bfin Xtensa is not yet supported in libnspr. Also add dependencies to libnss, which requires libnspr, and ecryptfs-utils, which requires libnss. Fixes (xtensa) http://autobuild.buildroot.net/results/14b/14ba6426edbffa100de924aa69157b3f59368ff2/ Fixes (blackfin) http://autobuild.buildroot.net/results/dd3/dd353703ed94cec48cd126d80cd2f1b039811be4/ [baruch: fix summary, add autobuild reference, add comment dependency, add blackfin] Signed-off-by: Chris Zankel <chris@zankel.net> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-11-27 16:48:39 +01:00
config BR2_PACKAGE_LIBNSPR_ARCH_SUPPORT
def_bool y
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_LIBNSPR_ARCH_SUPPORT
package: add libnspr Add a package for the Netscape Portable Runtime library. Signed-off-by: Will Newton <will.newton@imgtec.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-07-07 14:07:22 +02:00
config BR2_PACKAGE_LIBNSPR
bool "libnspr"
libnspr: requires thread support in toolchain Fixes http://autobuild.buildroot.org/results/58e0784e2289a60fa51589d2ce0a7a8ffe40f07e/build-end.log Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-09-17 08:44:34 +02:00
depends on BR2_TOOLCHAIN_HAS_THREADS
libnspr: needs dynamic library support The only package selecting libnspr (libnss) requires dynamic library already. Fixes: http://autobuild.buildroot.net/results/296/296bc0fd888a43700d2ea020f8486932c5d37760/ http://autobuild.buildroot.net/results/a65/a65588aa91a87f9a3d8af2a485de2df3e30cfc19/ Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-06-23 12:47:55 +02:00
depends on !BR2_STATIC_LIBS
package: add libnspr Add a package for the Netscape Portable Runtime library. Signed-off-by: Will Newton <will.newton@imgtec.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-07-07 14:07:22 +02:00
help
NSPR is the Netscape Portable Runtime library which provides
a platform-neutral API for system level and libc like
functions. The library is used by the Mozilla project as well
as others.
http://www.mozilla.org/projects/nspr/
libnspr: needs dynamic library support The only package selecting libnspr (libnss) requires dynamic library already. Fixes: http://autobuild.buildroot.net/results/296/296bc0fd888a43700d2ea020f8486932c5d37760/ http://autobuild.buildroot.net/results/a65/a65588aa91a87f9a3d8af2a485de2df3e30cfc19/ Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-06-23 12:47:55 +02:00
comment "libnspr needs a toolchain w/ threads, dynamic library"
depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS
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