[Buildroot] [PATCH v3 2/2] package/python-scipy: new package
esben at geanix.com
Mon Sep 30 08:18:49 UTC 2019
Arnout Vandecappelle <arnout at mind.be> writes:
> On 26/09/2019 16:10, Esben Haabendal wrote:
>> Arnout Vandecappelle <arnout at mind.be> writes:
>>> On 24/09/2019 16:39, Esben Haabendal wrote:
>>>> + select BR2_PACKAGE_PYTHON_NUMPY
>>>> + select BR2_PACKAGE_OPENBLAS
>>>> + select BR2_PACKAGE_CLAPACK
>>> This clapack, fortran, openblas stuff really needs some explanation in the
>>> commit message. Why clapack and not lapack or the lapack bundled with openblas?
>>> Why Fortran? etc.
>> I will try and add something.
>> Actually, I don't see why openblas is needed, as clapack can provide
>> both blas and lapack. Current python-numpy package uses clapack for
>> both, so it makes most sense to do the same here.
> That does indeed make the most sense. It will also make it easier to do the big
> lapack/blas cleanup that Romain is advocating.
> BTW, I don't think I ever commented on that. I agree with Romain that a cleanup
> is needed of the handling of (c)lapack and (c)blas - possibly with 4 virtual
> packages. However, I agree with Esben that it's OK to already include
> python-scipy before that cleanup is done. In a way, having another example of a
> use of those packages makes it easier to understand and be sure that the cleanup
> is done correctly.
Sounds good. I will proceed with a new version of this patch series.
>>>> + help
>>>> + The SciPy library is one of the core packages that make up the SciPy
>>>> + stack. It provides many user-friendly and efficient numerical
>>>> + routines such as routines for numerical integration, interpolation,
>>>> + optimization, linear algebra and statistics.
>>>> + https://www.scipy.org/scipylib/
>>>> +comment "python-scipy needs a toolchain w/ fortran"
>>>> + depends on !BR2_TOOLCHAIN_HAS_FORTRAN
>>> Python3 and glibc/musl dependency should be added as well, and the arch
>>> dependencies should be repeated. I.e.
>> glibc/musl dependency makes sense. But I don't think that python3 arch
>> dependencies should cause a comment.
> Not the python3 arch dependencies, but the python3 dependency itself (i.e. the
> !python2 part).
> However, apparently I'm wrong... Looking at other packages, apparently the
> python3 dependency should be treated like an arch dependency...
> Arch dependencies should be included as well, but to *hide* the comment in case
> they're not satisfied.
> Look at e.g. python-slob for an example.
Ok, I think I see what you mean. Let me know if I manage to get it
right in next version.
>>>> + Apache-2.0, MIT
>>>> +PYTHON_SCIPY_LICENSE_FILES = LICENSE.txt \
>>> Split the line before already, so
>>> PYTHON_SCIPY_LICENSE_FILES = \
>>> LICENSE.txt \
>> Is this policy? There are 23 examples of doing it that way, and 17 the
> By my count, the numbers are dramatically in favour of my proposal...
> $ git grep '^[A-Z0-9_]* +\?= [-A-Za-z0-9_$()]* \\$' -- \*.mk | wc
> 53 212 3743
> $ git grep '^[A-Z0-9_]* +\?= \\$' -- \*.mk | wc
> 1293 3879 72641
> The option of filling up the lines to 80 characters is a little bit more
> acceptable, but personally I'm not a fan...
> $ git grep '^[A-Z0-9_]* +\?= [-A-Za-z0-9_$()].*\\' -- \*.mk | wc
> 252 1325 22027
>> I will change it in next version, but are you sure which way is "the
>> right way"?
> I'll admit that this is something where no hard rule has been written down, so
> the patch should definitely be blocked by it.
You have me convinced. I will adapt to your proposal :)
>>> Also, I think it's useful to add the LICENSES_bundled.txt, because changes in
>>> that file should be noticed (i.e. the hash changes).
>> That file is not included in this scipy release we are using.
> Ah, sorry, I was looking at the git repo instead of the tarball.
I did the same thing, but obviously got in trouble when buildroot found
that the file was missing.
More information about the buildroot