[Buildroot] [PATCH v3 2/2] package/python-scipy: new package

[Esben Haabendal <esben@geanix.com>]

Arnout Vandecappelle <arnout@mind.be> writes:

> On 26/09/2019 16:10, Esben Haabendal wrote:
>> Arnout Vandecappelle <arnout@mind.be> writes:
>> 
>>> On 24/09/2019 16:39, Esben Haabendal wrote:
> [snip]
>>>> +	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
>> opposite.
>
>  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.

/Esben