* [Buildroot] [PATCH] [PATCHv3] package/python-numpy: fix occasional build failure with lapack @ 2019-07-10 14:19 Aalx 2019-07-10 22:34 ` Arnout Vandecappelle 0 siblings, 1 reply; 4+ messages in thread From: Aalx @ 2019-07-10 14:19 UTC (permalink / raw) To: buildroot python-numpy build fails if lapack or clapack are build before python-numpy itself, and this boesn't always happen because lapack dependency is missing in BR2_PYTHON_NUMPY_DEPENDENCIES. Also, clapack is a C implementation of FORTRAN lapack. At build time, they both generate the same liblapack.so file. But because lapack is written in FORTRAN then, it can be difficult to build. Both package are kept behind a virtual package named vlapack. They are mutually exclusive. Signed-off-by: Alexandre PAYEN <alexandre.payen@smile.fr> --- package/Config.in | 3 +- package/liblapack/Config.in | 86 ++++++++++++++++++++++++++++ package/liblapack/liblapack.mk | 7 +++ package/python-numpy/python-numpy.mk | 5 ++ 4 files changed, 99 insertions(+), 2 deletions(-) create mode 100644 package/liblapack/Config.in create mode 100644 package/liblapack/liblapack.mk diff --git a/package/Config.in b/package/Config.in index d501b5a65b..04c44b86e0 100644 --- a/package/Config.in +++ b/package/Config.in @@ -1663,7 +1663,6 @@ menu "Other" source "package/boost/Config.in" source "package/capnproto/Config.in" source "package/clang/Config.in" - source "package/clapack/Config.in" source "package/classpath/Config.in" source "package/cmocka/Config.in" source "package/cppcms/Config.in" @@ -1686,7 +1685,6 @@ menu "Other" source "package/gsl/Config.in" source "package/gtest/Config.in" source "package/jemalloc/Config.in" - source "package/lapack/Config.in" source "package/libargtable2/Config.in" source "package/libatomic_ops/Config.in" source "package/libb64/Config.in" @@ -1767,6 +1765,7 @@ endif source "package/tinycbor/Config.in" source "package/tz/Config.in" source "package/tzdata/Config.in" + source "package/liblapack/Config.in" source "package/xapian/Config.in" endmenu diff --git a/package/liblapack/Config.in b/package/liblapack/Config.in new file mode 100644 index 0000000000..fb155d7c02 --- /dev/null +++ b/package/liblapack/Config.in @@ -0,0 +1,86 @@ +config BR2_PACKAGE_VIRTUAL_LAPACK + bool "lapack support" + select BR2_PACKAGE_HAS_LAPACK + help + Select lapack library provider. + +if BR2_PACKAGE_VIRTUAL_LAPACK + +choice + prompt "lapack implementation" + default BR2_PACKAGE_LAPACK + help + Select lapack or clapack implementation. + + +comment "clapack needs a glibc toolchain" + depends on BR2_powerpc + depends on !BR2_TOOLCHAIN_USES_GLIBC + +config BR2_PACKAGE_CLAPACK + bool "C implementation" + # _fpu_control is used on PowerPC, but not available with + # uClibc or musl + depends on !BR2_powerpc || BR2_TOOLCHAIN_USES_GLIBC + # assembler: Error: value out of range + depends on !BR2_m68k_cf + help + LAPACK and BLAS C implementation (f2c'ed version of).' + + http://www.netlib.org/clapack/ + +if BR2_PACKAGE_CLAPACK + +config BR2_PACKAGE_CLAPACK_ARITH_H + string "Custom BLAS arith.h" + depends on BR2_PACKAGE_CLAPACK + help + To optimize BLAS library for the hardware, an 'arith.h' header + should be provided. + + If empty, the library will not be optimized by the compiler. + + In any case an 'arithchk' program is built + (but not installed), to be run on the target to generate this + arith.h header. + +endif + +comment "lapack/blas needs a toolchain w/ fortran" + depends on !(BR2_powerpc && BR2_TOOLCHAIN_USES_UCLIBC) + depends on !BR2_TOOLCHAIN_HAS_FORTRAN + +config BR2_PACKAGE_LAPACK + bool "FORTRAN implementation" + depends on BR2_TOOLCHAIN_HAS_FORTRAN + # _fpu_control is used on PowerPC, but not available with uClibc + depends on !(BR2_powerpc && BR2_TOOLCHAIN_USES_UCLIBC) + help + LAPACK and BLAS FORTRAN implementation. This package + installs two libraries: libblas and liblapack. + + http://www.netlib.org/lapack/ + +if BR2_PACKAGE_LAPACK + +config BR2_PACKAGE_LAPACK_COMPLEX + bool "Complex/Complex16 support" + default y + depends on BR2_PACKAGE_LAPACK + help + Builds support for COMPLEX and COMPLEX16 data types. + +endif + +endchoice + +config BR2_PACKAGE_HAS_VIRT_LAPACK + bool + +config BR2_PACKAGE_PROVIDES_VIRT_LAPACK + depends on BR2_PACKAGE_HAS_VIRT_LAPACK + string + default "lapack" if BR2_PACKAGE_LAPACK + default "clapack" if BR2_PACKAGE_CLAPACK + +endif diff --git a/package/liblapack/liblapack.mk b/package/liblapack/liblapack.mk new file mode 100644 index 0000000000..06cece60f9 --- /dev/null +++ b/package/liblapack/liblapack.mk @@ -0,0 +1,7 @@ +################################################################################ +# +# liblapack +# +################################################################################ + +$(eval $(virtual-package)) diff --git a/package/python-numpy/python-numpy.mk b/package/python-numpy/python-numpy.mk index 5d2fbfc7ad..71de61f6e3 100644 --- a/package/python-numpy/python-numpy.mk +++ b/package/python-numpy/python-numpy.mk @@ -17,7 +17,12 @@ PYTHON_NUMPY_SETUP_TYPE = setuptools ifeq ($(BR2_PACKAGE_CLAPACK),y) PYTHON_NUMPY_DEPENDENCIES += clapack +PYTHON_NUMPY_SITE_CFG_LIBS += cblas clapack +PYTHON_NUMPY_ENV += BLAS=clapack LAPACK=clapack +else ifeq ($(BR2_PACKAGE_LAPACK_COMPLEX),y) +PYTHON_NUMPY_DEPENDENCIES += lapack PYTHON_NUMPY_SITE_CFG_LIBS += blas lapack +PYTHON_NUMPY_ENV += BLAS=lapack LAPACK=lapack else PYTHON_NUMPY_ENV += BLAS=None LAPACK=None endif -- 2.21.0 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* [Buildroot] [PATCH] [PATCHv3] package/python-numpy: fix occasional build failure with lapack 2019-07-10 14:19 [Buildroot] [PATCH] [PATCHv3] package/python-numpy: fix occasional build failure with lapack Aalx @ 2019-07-10 22:34 ` Arnout Vandecappelle 2019-07-12 9:44 ` Alexandre PAYEN 0 siblings, 1 reply; 4+ messages in thread From: Arnout Vandecappelle @ 2019-07-10 22:34 UTC (permalink / raw) To: buildroot Hi Alexandre, Please set your user.name and user.email git config options to match your Signed-off-by. On 10/07/2019 16:19, Aalx wrote: > python-numpy build fails if lapack or clapack are build before python-numpy > itself, and this boesn't always happen because lapack dependency is missing in > BR2_PYTHON_NUMPY_DEPENDENCIES. Well, that's not true: for clapack, the dependency was already there. However, the SITE_CFG_LIBS and environment were referring to blas/lapack instead of cblas/clapack. > Also, clapack is a C implementation of FORTRAN lapack. At build time, they both > generate the same liblapack.so file. But because lapack is written in FORTRAN > then, it can be difficult to build. Both package are kept behind a virtual > package named vlapack. They are mutually exclusive. This is pretty much independent of the numpy fix, so should be a separate patch. Note, however, there are three ways to make them mutually exclusive. 1. Making it a virtual package - which is what you did. However, the main purpose of a virtual package is to make it possible to use it in select/depend without caring about which implementation is chosen. That might apply for lapack, I'm not sure. 2. Adding an explicit dependency from one on the other in Config.in. E.g. clapack could depend on !lapack. 3. Adding a dependency on something else which is mutually exclusive. lapack depends on BR2_TOOLCHAIN_HAS_FORTRAN, so you could just add a dependency on !BR2_TOOLCHAIN_HAS_FORTRAN to clapack. This makes sense, since the Fortran implementation is supposed to be the real source, and clapack is more or less automatically generated from it. Supposedly, lapack should optimise better than clapack. The commit log should explain that these three options exist, and why you choose that particular one. [snip] > diff --git a/package/liblapack/Config.in b/package/liblapack/Config.in > new file mode 100644 > index 0000000000..fb155d7c02 > --- /dev/null > +++ b/package/liblapack/Config.in > @@ -0,0 +1,86 @@ > +config BR2_PACKAGE_VIRTUAL_LAPACK The package name and Config.in symbol must correspond with each other. So if the package is called VIRTUAL_LAPACK, the directory and .mk file should be called virtual-lapack, etc. > + bool "lapack support" > + select BR2_PACKAGE_HAS_LAPACK > + help > + Select lapack library provider. > + > +if BR2_PACKAGE_VIRTUAL_LAPACK > + > +choice > + prompt "lapack implementation" > + default BR2_PACKAGE_LAPACK > + help > + Select lapack or clapack implementation. This is not formatted properly. Please use check-package to verify formatting. > + > + > +comment "clapack needs a glibc toolchain" > + depends on BR2_powerpc > + depends on !BR2_TOOLCHAIN_USES_GLIBC > + > +config BR2_PACKAGE_CLAPACK Unfortunately, it is not possible to put clapack in a choice at the moment, since armadillo selects it. So you need to adapt armadillo as well to select BR2_PACKAGE_VIRTUAL_LAPACK instead of BR2_PACKAGE_CLAPACK (and test that it works with lapack). Also, it is not possible to convert existing Config.in symbols into choice options, because that breaks existing configurations. Anyway, there is no real need for a choice. The normal use of a virtual package is to select the virtual package from the providers. But then, typically, the user of the virtual package would depend on it, rather than select it. > + bool "C implementation" > + # _fpu_control is used on PowerPC, but not available with > + # uClibc or musl > + depends on !BR2_powerpc || BR2_TOOLCHAIN_USES_GLIBC > + # assembler: Error: value out of range > + depends on !BR2_m68k_cf > + help > + LAPACK and BLAS C implementation (f2c'ed version of).' > + > + http://www.netlib.org/clapack/ > + > +if BR2_PACKAGE_CLAPACK > + > +config BR2_PACKAGE_CLAPACK_ARITH_H This has to go outside of the choice block. > + string "Custom BLAS arith.h" > + depends on BR2_PACKAGE_CLAPACK > + help > + To optimize BLAS library for the hardware, an 'arith.h' header > + should be provided. > + > + If empty, the library will not be optimized by the compiler. > + > + In any case an 'arithchk' program is built > + (but not installed), to be run on the target to generate this > + arith.h header. > + > +endif > + > +comment "lapack/blas needs a toolchain w/ fortran" > + depends on !(BR2_powerpc && BR2_TOOLCHAIN_USES_UCLIBC) > + depends on !BR2_TOOLCHAIN_HAS_FORTRAN > + > +config BR2_PACKAGE_LAPACK > + bool "FORTRAN implementation" > + depends on BR2_TOOLCHAIN_HAS_FORTRAN > + # _fpu_control is used on PowerPC, but not available with uClibc > + depends on !(BR2_powerpc && BR2_TOOLCHAIN_USES_UCLIBC) > + help > + LAPACK and BLAS FORTRAN implementation. This package > + installs two libraries: libblas and liblapack. > + > + http://www.netlib.org/lapack/ > + > +if BR2_PACKAGE_LAPACK > + > +config BR2_PACKAGE_LAPACK_COMPLEX This as well. > + bool "Complex/Complex16 support" > + default y > + depends on BR2_PACKAGE_LAPACK > + help > + Builds support for COMPLEX and COMPLEX16 data types. > + > +endif > + > +endchoice > + > +config BR2_PACKAGE_HAS_VIRT_LAPACK Again, this name should be the same as the package name, so BR2_PACKAGE_HAS_VIRTUAL_LAPACK. Regards, Arnout > + bool > + > +config BR2_PACKAGE_PROVIDES_VIRT_LAPACK > + depends on BR2_PACKAGE_HAS_VIRT_LAPACK > + string > + default "lapack" if BR2_PACKAGE_LAPACK > + default "clapack" if BR2_PACKAGE_CLAPACK > + > +endif > diff --git a/package/liblapack/liblapack.mk b/package/liblapack/liblapack.mk > new file mode 100644 > index 0000000000..06cece60f9 > --- /dev/null > +++ b/package/liblapack/liblapack.mk > @@ -0,0 +1,7 @@ > +################################################################################ > +# > +# liblapack > +# > +################################################################################ > + > +$(eval $(virtual-package)) > diff --git a/package/python-numpy/python-numpy.mk b/package/python-numpy/python-numpy.mk > index 5d2fbfc7ad..71de61f6e3 100644 > --- a/package/python-numpy/python-numpy.mk > +++ b/package/python-numpy/python-numpy.mk > @@ -17,7 +17,12 @@ PYTHON_NUMPY_SETUP_TYPE = setuptools > > ifeq ($(BR2_PACKAGE_CLAPACK),y) > PYTHON_NUMPY_DEPENDENCIES += clapack > +PYTHON_NUMPY_SITE_CFG_LIBS += cblas clapack > +PYTHON_NUMPY_ENV += BLAS=clapack LAPACK=clapack > +else ifeq ($(BR2_PACKAGE_LAPACK_COMPLEX),y) > +PYTHON_NUMPY_DEPENDENCIES += lapack > PYTHON_NUMPY_SITE_CFG_LIBS += blas lapack > +PYTHON_NUMPY_ENV += BLAS=lapack LAPACK=lapack > else > PYTHON_NUMPY_ENV += BLAS=None LAPACK=None > endif > ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Buildroot] [PATCH] [PATCHv3] package/python-numpy: fix occasional build failure with lapack 2019-07-10 22:34 ` Arnout Vandecappelle @ 2019-07-12 9:44 ` Alexandre PAYEN 2019-07-12 20:46 ` Arnout Vandecappelle 0 siblings, 1 reply; 4+ messages in thread From: Alexandre PAYEN @ 2019-07-12 9:44 UTC (permalink / raw) To: buildroot Hi Arnout, Thanks for reviewing. It is my very first attempt. Following this mail, a new try. Le jeu. 11 juil. 2019 ? 00:34, Arnout Vandecappelle <arnout@mind.be> a ?crit : > Hi Alexandre, > > Please set your user.name and user.email git config options to match your > Signed-off-by. > > On 10/07/2019 16:19, Aalx wrote: > > python-numpy build fails if lapack or clapack are build before > python-numpy > > itself, and this boesn't always happen because lapack dependency is > missing in > > BR2_PYTHON_NUMPY_DEPENDENCIES. > > Well, that's not true: for clapack, the dependency was already there. > However, > the SITE_CFG_LIBS and environment were referring to blas/lapack instead of > cblas/clapack. Okay, I will fix this. > > > > Also, clapack is a C implementation of FORTRAN lapack. At build time, > they both > > generate the same liblapack.so file. But because lapack is written in > FORTRAN > > then, it can be difficult to build. Both package are kept behind a > virtual > > package named vlapack. They are mutually exclusive. > > This is pretty much independent of the numpy fix, so should be a separate > patch. > > Note, however, there are three ways to make them mutually exclusive. > > 1. Making it a virtual package - which is what you did. However, the main > purpose of a virtual package is to make it possible to use it in > select/depend > without caring about which implementation is chosen. That might apply for > lapack, I'm not sure. > > 2. Adding an explicit dependency from one on the other in Config.in. E.g. > clapack could depend on !lapack. > It has already been discussed. That is why I choose the virtual package solution. > > 3. Adding a dependency on something else which is mutually exclusive. > lapack > depends on BR2_TOOLCHAIN_HAS_FORTRAN, so you could just add a dependency on > !BR2_TOOLCHAIN_HAS_FORTRAN to clapack. This makes sense, since the Fortran > implementation is supposed to be the real source, and clapack is more or > less > automatically generated from it. Supposedly, lapack should optimise better > than > clapack. > > > The commit log should explain that these three options exist, and why you > choose that particular one. > > [snip] > > diff --git a/package/liblapack/Config.in b/package/liblapack/Config.in > > new file mode 100644 > > index 0000000000..fb155d7c02 > > --- /dev/null > > +++ b/package/liblapack/Config.in > > @@ -0,0 +1,86 @@ > > +config BR2_PACKAGE_VIRTUAL_LAPACK > > The package name and Config.in symbol must correspond with each other. So > if > the package is called VIRTUAL_LAPACK, the directory and .mk file should be > called virtual-lapack, etc. > My bad, I renamed the virtual package as liblapack at the end and I forget to fix it here. You can see vlapack in the commit message too. > > > + bool "lapack support" > > + select BR2_PACKAGE_HAS_LAPACK > > + help > > + Select lapack library provider. > > + > > +if BR2_PACKAGE_VIRTUAL_LAPACK > > + > > +choice > > + prompt "lapack implementation" > > + default BR2_PACKAGE_LAPACK > > + help > > + Select lapack or clapack implementation. > > This is not formatted properly. Please use check-package to verify > formatting. > I did not know about check-package, now my package is properly formatting. Thx. > > > + > > + > > +comment "clapack needs a glibc toolchain" > > + depends on BR2_powerpc > > + depends on !BR2_TOOLCHAIN_USES_GLIBC > > + > > +config BR2_PACKAGE_CLAPACK > > Unfortunately, it is not possible to put clapack in a choice at the > moment, > since armadillo selects it. So you need to adapt armadillo as well to > select > BR2_PACKAGE_VIRTUAL_LAPACK instead of BR2_PACKAGE_CLAPACK (and test that it > works with lapack). > I'm currently testing. > > Also, it is not possible to convert existing Config.in symbols into choice > options, because that breaks existing configurations. > Which configuration does it break except armadillo ? In `git grep LAPACK` only python-numpy and armadillo use lapack or clapack. > > Anyway, there is no real need for a choice. The normal use of a virtual > package > is to select the virtual package from the providers. But then, typically, > the > user of the virtual package would depend on it, rather than select it. > lapack is selected by default if there is a FORTRAN compiler (as you said, I guess that lapack is more efficient than clapack). If there is no FORTRAN compiler, clapack is selected by default. The user should only select one if he need special option like the path of header file `arith.h`. > > > + bool "C implementation" > > + # _fpu_control is used on PowerPC, but not available with > > + # uClibc or musl > > + depends on !BR2_powerpc || BR2_TOOLCHAIN_USES_GLIBC > > + # assembler: Error: value out of range > > + depends on !BR2_m68k_cf > > + help > > + LAPACK and BLAS C implementation (f2c'ed version of).' > > + > > + http://www.netlib.org/clapack/ > > + > > +if BR2_PACKAGE_CLAPACK > > + > > +config BR2_PACKAGE_CLAPACK_ARITH_H > > This has to go outside of the choice block. > Ok > > > + string "Custom BLAS arith.h" > > + depends on BR2_PACKAGE_CLAPACK > > + help > > + To optimize BLAS library for the hardware, an 'arith.h' header > > + should be provided. > > + > > + If empty, the library will not be optimized by the compiler. > > + > > + In any case an 'arithchk' program is built > > + (but not installed), to be run on the target to generate this > > + arith.h header. > > + > > +endif > > + > > +comment "lapack/blas needs a toolchain w/ fortran" > > + depends on !(BR2_powerpc && BR2_TOOLCHAIN_USES_UCLIBC) > > + depends on !BR2_TOOLCHAIN_HAS_FORTRAN > > + > > +config BR2_PACKAGE_LAPACK > > + bool "FORTRAN implementation" > > + depends on BR2_TOOLCHAIN_HAS_FORTRAN > > + # _fpu_control is used on PowerPC, but not available with uClibc > > + depends on !(BR2_powerpc && BR2_TOOLCHAIN_USES_UCLIBC) > > + help > > + LAPACK and BLAS FORTRAN implementation. This package > > + installs two libraries: libblas and liblapack. > > + > > + http://www.netlib.org/lapack/ > > + > > +if BR2_PACKAGE_LAPACK > > + > > +config BR2_PACKAGE_LAPACK_COMPLEX > > This as well. > Ok as well. > > > + bool "Complex/Complex16 support" > > + default y > > + depends on BR2_PACKAGE_LAPACK > > + help > > + Builds support for COMPLEX and COMPLEX16 data types. > > + > > +endif > > + > > +endchoice > > + > > +config BR2_PACKAGE_HAS_VIRT_LAPACK > > Again, this name should be the same as the package name, so > BR2_PACKAGE_HAS_VIRTUAL_LAPACK. > > Regards, > Arnout > > > + bool > > + > > +config BR2_PACKAGE_PROVIDES_VIRT_LAPACK > > + depends on BR2_PACKAGE_HAS_VIRT_LAPACK > > + string > > + default "lapack" if BR2_PACKAGE_LAPACK > > + default "clapack" if BR2_PACKAGE_CLAPACK > > + > > +endif > > diff --git a/package/liblapack/liblapack.mk b/package/liblapack/ > liblapack.mk > > new file mode 100644 > > index 0000000000..06cece60f9 > > --- /dev/null > > +++ b/package/liblapack/liblapack.mk > > @@ -0,0 +1,7 @@ > > > +################################################################################ > > +# > > +# liblapack > > +# > > > +################################################################################ > > + > > +$(eval $(virtual-package)) > > diff --git a/package/python-numpy/python-numpy.mk > b/package/python-numpy/python-numpy.mk > > index 5d2fbfc7ad..71de61f6e3 100644 > > --- a/package/python-numpy/python-numpy.mk > > +++ b/package/python-numpy/python-numpy.mk > > @@ -17,7 +17,12 @@ PYTHON_NUMPY_SETUP_TYPE = setuptools > > > > ifeq ($(BR2_PACKAGE_CLAPACK),y) > > PYTHON_NUMPY_DEPENDENCIES += clapack > > +PYTHON_NUMPY_SITE_CFG_LIBS += cblas clapack > > +PYTHON_NUMPY_ENV += BLAS=clapack LAPACK=clapack > > +else ifeq ($(BR2_PACKAGE_LAPACK_COMPLEX),y) > > +PYTHON_NUMPY_DEPENDENCIES += lapack > > PYTHON_NUMPY_SITE_CFG_LIBS += blas lapack > > +PYTHON_NUMPY_ENV += BLAS=lapack LAPACK=lapack > > else > > PYTHON_NUMPY_ENV += BLAS=None LAPACK=None > > endif > > > Bye, Alexandre -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20190712/3aae0e66/attachment.html> ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Buildroot] [PATCH] [PATCHv3] package/python-numpy: fix occasional build failure with lapack 2019-07-12 9:44 ` Alexandre PAYEN @ 2019-07-12 20:46 ` Arnout Vandecappelle 0 siblings, 0 replies; 4+ messages in thread From: Arnout Vandecappelle @ 2019-07-12 20:46 UTC (permalink / raw) To: buildroot Hi Alex, On 12/07/2019 11:44, Alexandre PAYEN wrote: [snip] > > Also, clapack is a C implementation of FORTRAN lapack. At build time, they > both > > generate the same liblapack.so file. But because lapack is written in FORTRAN > > then, it can be difficult to build. Both package are kept behind a virtual > > package named vlapack. They are mutually exclusive. > > ?This is pretty much independent of the numpy fix, so should be a separate > patch. > > ?Note, however, there are three ways to make them mutually exclusive. > > 1. Making it a virtual package - which is what you did. However, the main > purpose of a virtual package is to make it possible to use it in select/depend > without caring about which implementation is chosen. That might apply for > lapack, I'm not sure. > > 2. Adding an explicit dependency from one on the other in Config.in. E.g. > clapack could depend on !lapack. > > It has already been discussed. That is why I choose the virtual package solution. I know My point was, however... > > > 3. Adding a dependency on something else which is mutually exclusive. lapack > depends on BR2_TOOLCHAIN_HAS_FORTRAN, so you could just add a dependency on > !BR2_TOOLCHAIN_HAS_FORTRAN to clapack. This makes sense, since the Fortran > implementation is supposed to be the real source, and clapack is more or less > automatically generated from it. Supposedly, lapack should optimise better than > clapack. > > > ?The commit log should explain that these three options exist, and why you > choose that particular one. ... this ^^^^. The rest was a reminder that those are the options. [snip] > ?Also, it is not possible to convert existing Config.in symbols into choice > options, because that breaks existing configurations. > > Which configuration does it break except armadillo ? > In `git grep LAPACK` only python-numpy and armadillo use lapack or clapack. I mean the following: *Before* your patch. select BR2_PACKAGE_LAPACK. Now, apply your patch. Do 'make menuconfig', and you'll see that BR2_PACKAGE_LAPACK is no longer selected. That's a problem. > Anyway, there is no real need for a choice. The normal use of a virtual package > is to select the virtual package from the providers. But then, typically, the > user of the virtual package would depend on it, rather than select it. > > lapack is selected by default if there is a FORTRAN compiler (as you said, I > guess that > lapack is more efficient than clapack). > If there is no FORTRAN compiler, clapack is selected by default. The user should > only select one > if he need special option like the path of header file `arith.h`. If there would be a package that needs clapack specifically, it is not possible for that package to select clapack (because it's now part of a choice). That's a bit annoying. But since no such package exists, probably not important. Regards, Arnout [snip] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-07-12 20:46 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-07-10 14:19 [Buildroot] [PATCH] [PATCHv3] package/python-numpy: fix occasional build failure with lapack Aalx 2019-07-10 22:34 ` Arnout Vandecappelle 2019-07-12 9:44 ` Alexandre PAYEN 2019-07-12 20:46 ` Arnout Vandecappelle
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.