[Buildroot] [PATCH 1/2] package/python-pybind: fix upgrade to version 2.6.1

[Buildroot] [PATCH 1/2] package/python-pybind: fix upgrade to version 2.6.1

[guillaume.bressaix]

From: "Guillaume W. Bres" <guillaume.bressaix@gmail.com>

The python 'setup.py' script needs header files
in $(@D)/pybind11 to work since v2.6.1, and these files
are created by an internal minimalist cmake build.

fixes http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d
fixes http://autobuild.buildroot.net/results/d0287b7f64f206b0f074908c5780a3632e0cb799
fixes http://autobuild.buildroot.net/results/27efb545a5a719a5581c8f746d3a3555ff4216ce
fixes http://autobuild.buildroot.net/results/d2f0a0ad8f6c7178517df109e7d885dac9134c3a
fixes http://autobuild.buildroot.net/results/b57e9a3279260dae4a590f9421238fcabb2f7cab
fixes http://autobuild.buildroot.net/results/515e6f2fc6b5780260d98d6bb52b541ce4bf1afe
fixes http://autobuild.buildroot.net/results/d89c4ecc81222d4f80c951da2232d2e393fa1c69

Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>

---
This remains a python-package.

'python setup.py' actually hardcodes a system call to cmake,
which seems dirty at first.
Fortunately, if we have CMAKE ENV, all BR variables are retrieved.
I think they made this cmake call to make setup.py self sufficient.

---
 package/python-pybind/python-pybind.mk | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/package/python-pybind/python-pybind.mk b/package/python-pybind/python-pybind.mk
index a6a1bdb976..080586a877 100644
--- a/package/python-pybind/python-pybind.mk
+++ b/package/python-pybind/python-pybind.mk
@@ -9,5 +9,11 @@ PYTHON_PYBIND_SITE = $(call github,pybind,pybind11,v$(PYTHON_PYBIND_VERSION))
 PYTHON_PYBIND_LICENSE = BSD-3-Clause
 PYTHON_PYBIND_LICENSE_FILES = LICENSE
 PYTHON_PYBIND_SETUP_TYPE = setuptools
+PYTHON_PYBIND_INSTALL_STAGING = YES
+
+# every single 'python setup.py' call actually calls cmake
+# to populate $(@D)/pybind11 with .h and build requirements.
+# If we have a HOST_CMAKE_ENV, then installation paths are properly defined
+PYTHON_PYBIND_DEPENDENCIES = host-cmake
 
 $(eval $(python-package))
-- 
2.20.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 2/2] package/python-pybind: bump to version 2.8.1

[guillaume.bressaix]

From: "Guillaume W. Bres" <guillaume.bressaix@gmail.com>

Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
---
 package/python-pybind/python-pybind.hash | 2 +-
 package/python-pybind/python-pybind.mk   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/python-pybind/python-pybind.hash b/package/python-pybind/python-pybind.hash
index a68ac846e2..e1d86a4494 100644
--- a/package/python-pybind/python-pybind.hash
+++ b/package/python-pybind/python-pybind.hash
@@ -1,4 +1,4 @@
 # Locally calculated
-sha256  cdbe326d357f18b83d10322ba202d69f11b2f49e2d87ade0dc2be0c5c34f8e2a  python-pybind-2.6.1.tar.gz
+sha256  f1bcc07caa568eb312411dde5308b1e250bd0e1bc020fae855bf9f43209940cc  python-pybind-2.8.1.tar.gz
 # License files, locally calculated
 sha256  83965b843b98f670d3a85bd041ed4b372c8ec50d7b4a5995a83ac697ba675dcb  LICENSE
diff --git a/package/python-pybind/python-pybind.mk b/package/python-pybind/python-pybind.mk
index 080586a877..5519e80527 100644
--- a/package/python-pybind/python-pybind.mk
+++ b/package/python-pybind/python-pybind.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-PYTHON_PYBIND_VERSION = 2.6.1
+PYTHON_PYBIND_VERSION = 2.8.1
 PYTHON_PYBIND_SITE = $(call github,pybind,pybind11,v$(PYTHON_PYBIND_VERSION))
 PYTHON_PYBIND_LICENSE = BSD-3-Clause
 PYTHON_PYBIND_LICENSE_FILES = LICENSE
-- 
2.20.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/python-pybind: fix upgrade to version 2.6.1

[Arnout Vandecappelle]

  Hi Guillaume,

  This is still looking fairly weird to me...

On 05/12/2021 21:47, guillaume.bressaix@gmail.com wrote:
> From: "Guillaume W. Bres" <guillaume.bressaix@gmail.com>
> 
> The python 'setup.py' script needs header files
> in $(@D)/pybind11 to work since v2.6.1, and these files
> are created by an internal minimalist cmake build.
> 
> fixes http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d

  Nitpick: to make it appear with the fixes tag in patchwork or in the summary 
that Peter makes, you have to format it like this:

Fixes:
     http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d
     http://...

> fixes http://autobuild.buildroot.net/results/d0287b7f64f206b0f074908c5780a3632e0cb799
> fixes http://autobuild.buildroot.net/results/27efb545a5a719a5581c8f746d3a3555ff4216ce
> fixes http://autobuild.buildroot.net/results/d2f0a0ad8f6c7178517df109e7d885dac9134c3a
> fixes http://autobuild.buildroot.net/results/b57e9a3279260dae4a590f9421238fcabb2f7cab
> fixes http://autobuild.buildroot.net/results/515e6f2fc6b5780260d98d6bb52b541ce4bf1afe
> fixes http://autobuild.buildroot.net/results/d89c4ecc81222d4f80c951da2232d2e393fa1c69
> 
> Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
> 
> ---
> This remains a python-package.
> 
> 'python setup.py' actually hardcodes a system call to cmake,
> which seems dirty at first.
> Fortunately, if we have CMAKE ENV, all BR variables are retrieved.

  I don't see CMAKE_ENV anywhere in Buildroot, or in this patch.

  Also, I don't think there's any way to tell CMake about "all BR variables" 
other than passing a toolchainfile (with -DCMAKE_TOOLCHAIN_FILE=...). Are you 
sure that it's really building correctly for the target?


  Regards,
  Arnout


> I think they made this cmake call to make setup.py self sufficient.
> 
> ---
>   package/python-pybind/python-pybind.mk | 6 ++++++
>   1 file changed, 6 insertions(+)
> 
> diff --git a/package/python-pybind/python-pybind.mk b/package/python-pybind/python-pybind.mk
> index a6a1bdb976..080586a877 100644
> --- a/package/python-pybind/python-pybind.mk
> +++ b/package/python-pybind/python-pybind.mk
> @@ -9,5 +9,11 @@ PYTHON_PYBIND_SITE = $(call github,pybind,pybind11,v$(PYTHON_PYBIND_VERSION))
>   PYTHON_PYBIND_LICENSE = BSD-3-Clause
>   PYTHON_PYBIND_LICENSE_FILES = LICENSE
>   PYTHON_PYBIND_SETUP_TYPE = setuptools
> +PYTHON_PYBIND_INSTALL_STAGING = YES
> +
> +# every single 'python setup.py' call actually calls cmake
> +# to populate $(@D)/pybind11 with .h and build requirements.
> +# If we have a HOST_CMAKE_ENV, then installation paths are properly defined
> +PYTHON_PYBIND_DEPENDENCIES = host-cmake
>   
>   $(eval $(python-package))
> 
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/python-pybind: fix upgrade to version 2.6.1

[Guillaume Bres]

[-- Attachment #1.1: Type: text/plain, Size: 5324 bytes --]

Arnout,
thanks for the quick review

>Nitpick: to make it appear with the fixes tag in patchwork or in the
summary
>that Peter makes, you have to format it like this:
thanks, never done that before, I will correct that in a V2

>I don't see CMAKE_ENV anywhere in Buildroot, or in this patch.
I just meant the general cmake env. I will correct/improve my explanations
in a V2,
especially those, because they are to remain visible to clarify things in
case of future problems.

>  This is still looking fairly weird to me...
>Also, I don't think there's any way to tell CMake about "all BR variables"
>other than passing a toolchainfile (with -DCMAKE_TOOLCHAIN_FILE=...). Are
you
>sure that it's really building correctly for the target?
the package is broken, it put on hold for about 3 years now, some
interesting contributions I would like to submit. It would be nice to fix
it.

Yesterday you explained the pkg name and build infrastructure are total
different things and we agreed to convert to a cmake package.
In the meantime, I was exploring both options, with my goal being able to
provide target + staging + host (basically all 3) combinations.

I decided to keep it as a python-pkg and submit this content, in spite of
our conversation, as I ran into this fix unexpectedly.
I actually works (tested on 2 platforms), the intrinsic build failure is
fixed.

With the cmake-package option, that I also inquired intensively, I never
get a staging + target install, build fails.
With this option, all combinations pass.

>sure that it's really building correctly for the target?
My next submission is scipy and it relies on the host- version of this pkg
(now supposedly 2.8.1 if you merge patch #2).
And I just redid a test of the produced scipy binaries on my zedboard, they
work fine.
The problem to answer fully your question is that:
* no pkg currently depend on pybind
* my next submission depends on host-pybind (to be submitted after all the
fixing), not on target-pybind.
This is why I wanted to move this pkg to a host-only package, but Yann
corrected otherwise

I will wait for you answer before submitting a V2 depending on what we
decide

Guillaume W. Bres
Software engineer
<guillaume.bressaix@gmail.com>


Le lun. 6 déc. 2021 à 08:45, Arnout Vandecappelle <arnout@mind.be> a écrit :

>   Hi Guillaume,
>
>   This is still looking fairly weird to me...
>
> On 05/12/2021 21:47, guillaume.bressaix@gmail.com wrote:
> > From: "Guillaume W. Bres" <guillaume.bressaix@gmail.com>
> >
> > The python 'setup.py' script needs header files
> > in $(@D)/pybind11 to work since v2.6.1, and these files
> > are created by an internal minimalist cmake build.
> >
> > fixes
> http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d
>
>   Nitpick: to make it appear with the fixes tag in patchwork or in the
> summary
> that Peter makes, you have to format it like this:
>
> Fixes:
>
> http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d
>      http://...
>
> > fixes
> http://autobuild.buildroot.net/results/d0287b7f64f206b0f074908c5780a3632e0cb799
> > fixes
> http://autobuild.buildroot.net/results/27efb545a5a719a5581c8f746d3a3555ff4216ce
> > fixes
> http://autobuild.buildroot.net/results/d2f0a0ad8f6c7178517df109e7d885dac9134c3a
> > fixes
> http://autobuild.buildroot.net/results/b57e9a3279260dae4a590f9421238fcabb2f7cab
> > fixes
> http://autobuild.buildroot.net/results/515e6f2fc6b5780260d98d6bb52b541ce4bf1afe
> > fixes
> http://autobuild.buildroot.net/results/d89c4ecc81222d4f80c951da2232d2e393fa1c69
> >
> > Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
> >
> > ---
> > This remains a python-package.
> >
> > 'python setup.py' actually hardcodes a system call to cmake,
> > which seems dirty at first.
> > Fortunately, if we have CMAKE ENV, all BR variables are retrieved.
>
>   I don't see CMAKE_ENV anywhere in Buildroot, or in this patch.
>
>   Also, I don't think there's any way to tell CMake about "all BR
> variables"
> other than passing a toolchainfile (with -DCMAKE_TOOLCHAIN_FILE=...). Are
> you
> sure that it's really building correctly for the target?
>
>
>   Regards,
>   Arnout
>
>
> > I think they made this cmake call to make setup.py self sufficient.
> >
> > ---
> >   package/python-pybind/python-pybind.mk | 6 ++++++
> >   1 file changed, 6 insertions(+)
> >
> > diff --git a/package/python-pybind/python-pybind.mk
> b/package/python-pybind/python-pybind.mk
> > index a6a1bdb976..080586a877 100644
> > --- a/package/python-pybind/python-pybind.mk
> > +++ b/package/python-pybind/python-pybind.mk
> > @@ -9,5 +9,11 @@ PYTHON_PYBIND_SITE = $(call
> github,pybind,pybind11,v$(PYTHON_PYBIND_VERSION))
> >   PYTHON_PYBIND_LICENSE = BSD-3-Clause
> >   PYTHON_PYBIND_LICENSE_FILES = LICENSE
> >   PYTHON_PYBIND_SETUP_TYPE = setuptools
> > +PYTHON_PYBIND_INSTALL_STAGING = YES
> > +
> > +# every single 'python setup.py' call actually calls cmake
> > +# to populate $(@D)/pybind11 with .h and build requirements.
> > +# If we have a HOST_CMAKE_ENV, then installation paths are properly
> defined
> > +PYTHON_PYBIND_DEPENDENCIES = host-cmake
> >
> >   $(eval $(python-package))
> >
>

[-- Attachment #1.2: Type: text/html, Size: 8161 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/python-pybind: fix upgrade to version 2.6.1

[Arnout Vandecappelle]

On 06/12/2021 13:39, Guillaume Bres wrote:
> Arnout,
> thanks for the quick review
> 
>  >Nitpick: to make it appear with the fixes tag in patchwork or in the summary
>  >that Peter makes, you have to format it like this:
> thanks, never done that before, I will correct that in a V2
> 
>  >I don't see CMAKE_ENV anywhere in Buildroot, or in this patch.
> I just meant the general cmake env. I will correct/improve my explanations in a V2,
> especially those, because they are to remain visible to clarify things in case 
> of future problems.
> 
>  >  This is still looking fairly weird to me...
>  >Also, I don't think there's any way to tell CMake about "all BR variables"
>  >other than passing a toolchainfile (with -DCMAKE_TOOLCHAIN_FILE=...). Are you
>  >sure that it's really building correctly for the target?
> the package is broken, it put on hold for about 3 years now, some 
> interesting contributions I would like to submit. It would be nice to fix it.
> 
> Yesterday you explained the pkg name and build infrastructure are total 
> different things and we agreed to convert to a cmake package.
> In the meantime, I was exploring both options, with my goal being able to 
> provide target + staging + host (basically all 3) combinations.
> 
> I decided to keep it as a python-pkg and submit this content, in spite of our 
> conversation, as I ran into this fix unexpectedly.
> I actually works (tested on 2 platforms), the intrinsic build failure is fixed.
> 
> With the cmake-package option, that I also inquired intensively, I never get a 
> staging + target install, build fails.
> With this option, all combinations pass.

  OK, excellent, then the current patch is good enough. You're of course welcome 
to submit a v2 with fixed commit message and comments.


>  >sure that it's really building correctly for the target?
> My next submission is scipy and it relies on the host- version of this pkg (now 
> supposedly 2.8.1 if you merge patch #2).
> And I just redid a test of the produced scipy binaries on my zedboard, they work 
> fine.
> The problem to answer fully your question is that:
> * no pkg currently depend on pybind
> * my next submission depends on host-pybind (to be submitted after all the 
> fixing), not on target-pybind.
> This is why I wanted to move this pkg to a host-only package, but Yann corrected 
> otherwise

  You yourself submitted the pybind package about a year ago. What was it for 
then? Was it already for scipy? Was it just by accident that you submitted a 
target version instead of a host version?

  Regards,
  Arnout

> 
> I will wait for you answer before submitting a V2 depending on what we decide
> 
> Guillaume W. Bres
> Software engineer
> <guillaume.bressaix@gmail.com <mailto:guillaume.bressaix@gmail.com>>
> 
> 
> Le lun. 6 déc. 2021 à 08:45, Arnout Vandecappelle <arnout@mind.be 
> <mailto:arnout@mind.be>> a écrit :
> 
>        Hi Guillaume,
> 
>        This is still looking fairly weird to me...
> 
>     On 05/12/2021 21:47, guillaume.bressaix@gmail.com
>     <mailto:guillaume.bressaix@gmail.com> wrote:
>      > From: "Guillaume W. Bres" <guillaume.bressaix@gmail.com
>     <mailto:guillaume.bressaix@gmail.com>>
>      >
>      > The python 'setup.py' script needs header files
>      > in $(@D)/pybind11 to work since v2.6.1, and these files
>      > are created by an internal minimalist cmake build.
>      >
>      > fixes
>     http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d
>     <http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d>
> 
>        Nitpick: to make it appear with the fixes tag in patchwork or in the summary
>     that Peter makes, you have to format it like this:
> 
>     Fixes:
>     http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d
>     <http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d>
>           http://...
> 
>      > fixes
>     http://autobuild.buildroot.net/results/d0287b7f64f206b0f074908c5780a3632e0cb799
>     <http://autobuild.buildroot.net/results/d0287b7f64f206b0f074908c5780a3632e0cb799>
>      > fixes
>     http://autobuild.buildroot.net/results/27efb545a5a719a5581c8f746d3a3555ff4216ce
>     <http://autobuild.buildroot.net/results/27efb545a5a719a5581c8f746d3a3555ff4216ce>
>      > fixes
>     http://autobuild.buildroot.net/results/d2f0a0ad8f6c7178517df109e7d885dac9134c3a
>     <http://autobuild.buildroot.net/results/d2f0a0ad8f6c7178517df109e7d885dac9134c3a>
>      > fixes
>     http://autobuild.buildroot.net/results/b57e9a3279260dae4a590f9421238fcabb2f7cab
>     <http://autobuild.buildroot.net/results/b57e9a3279260dae4a590f9421238fcabb2f7cab>
>      > fixes
>     http://autobuild.buildroot.net/results/515e6f2fc6b5780260d98d6bb52b541ce4bf1afe
>     <http://autobuild.buildroot.net/results/515e6f2fc6b5780260d98d6bb52b541ce4bf1afe>
>      > fixes
>     http://autobuild.buildroot.net/results/d89c4ecc81222d4f80c951da2232d2e393fa1c69
>     <http://autobuild.buildroot.net/results/d89c4ecc81222d4f80c951da2232d2e393fa1c69>
>      >
>      > Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com
>     <mailto:guillaume.bressaix@gmail.com>>
>      >
>      > ---
>      > This remains a python-package.
>      >
>      > 'python setup.py' actually hardcodes a system call to cmake,
>      > which seems dirty at first.
>      > Fortunately, if we have CMAKE ENV, all BR variables are retrieved.
> 
>        I don't see CMAKE_ENV anywhere in Buildroot, or in this patch.
> 
>        Also, I don't think there's any way to tell CMake about "all BR variables"
>     other than passing a toolchainfile (with -DCMAKE_TOOLCHAIN_FILE=...). Are you
>     sure that it's really building correctly for the target?
> 
> 
>        Regards,
>        Arnout
> 
> 
>      > I think they made this cmake call to make setup.py self sufficient.
>      >
>      > ---
>      >   package/python-pybind/python-pybind.mk <http://python-pybind.mk> | 6 ++++++
>      >   1 file changed, 6 insertions(+)
>      >
>      > diff --git a/package/python-pybind/python-pybind.mk
>     <http://python-pybind.mk> b/package/python-pybind/python-pybind.mk
>     <http://python-pybind.mk>
>      > index a6a1bdb976..080586a877 100644
>      > --- a/package/python-pybind/python-pybind.mk <http://python-pybind.mk>
>      > +++ b/package/python-pybind/python-pybind.mk <http://python-pybind.mk>
>      > @@ -9,5 +9,11 @@ PYTHON_PYBIND_SITE = $(call
>     github,pybind,pybind11,v$(PYTHON_PYBIND_VERSION))
>      >   PYTHON_PYBIND_LICENSE = BSD-3-Clause
>      >   PYTHON_PYBIND_LICENSE_FILES = LICENSE
>      >   PYTHON_PYBIND_SETUP_TYPE = setuptools
>      > +PYTHON_PYBIND_INSTALL_STAGING = YES
>      > +
>      > +# every single 'python setup.py' call actually calls cmake
>      > +# to populate $(@D)/pybind11 with .h and build requirements.
>      > +# If we have a HOST_CMAKE_ENV, then installation paths are properly defined
>      > +PYTHON_PYBIND_DEPENDENCIES = host-cmake
>      >
>      >   $(eval $(python-package))
>      >
> 
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/python-pybind: fix upgrade to version 2.6.1

[Guillaume Bres]

[-- Attachment #1.1: Type: text/plain, Size: 8294 bytes --]

Arnout,
I am submitting a revised version of these patches, please discard v1

>What was it for then? Was it already for scipy?
yep

>  Was it just by accident that you submitted a target version instead of a
host version?
I don't really know why I did so, but at the time I decided I would unlock
the host-pkg version in the scipy patch that requires it.
Actually it still has to be done because we might fix the pkg today, but
that won't be enough for future dependencies

Guillaume W. Bres
Software engineer
<guillaume.bressaix@gmail.com>


Le lun. 6 déc. 2021 à 14:20, Arnout Vandecappelle <arnout@mind.be> a écrit :

>
>
> On 06/12/2021 13:39, Guillaume Bres wrote:
> > Arnout,
> > thanks for the quick review
> >
> >  >Nitpick: to make it appear with the fixes tag in patchwork or in the
> summary
> >  >that Peter makes, you have to format it like this:
> > thanks, never done that before, I will correct that in a V2
> >
> >  >I don't see CMAKE_ENV anywhere in Buildroot, or in this patch.
> > I just meant the general cmake env. I will correct/improve my
> explanations in a V2,
> > especially those, because they are to remain visible to clarify things
> in case
> > of future problems.
> >
> >  >  This is still looking fairly weird to me...
> >  >Also, I don't think there's any way to tell CMake about "all BR
> variables"
> >  >other than passing a toolchainfile (with -DCMAKE_TOOLCHAIN_FILE=...).
> Are you
> >  >sure that it's really building correctly for the target?
> > the package is broken, it put on hold for about 3 years now, some
> > interesting contributions I would like to submit. It would be nice to
> fix it.
> >
> > Yesterday you explained the pkg name and build infrastructure are total
> > different things and we agreed to convert to a cmake package.
> > In the meantime, I was exploring both options, with my goal being able
> to
> > provide target + staging + host (basically all 3) combinations.
> >
> > I decided to keep it as a python-pkg and submit this content, in spite
> of our
> > conversation, as I ran into this fix unexpectedly.
> > I actually works (tested on 2 platforms), the intrinsic build failure is
> fixed.
> >
> > With the cmake-package option, that I also inquired intensively, I never
> get a
> > staging + target install, build fails.
> > With this option, all combinations pass.
>
>   OK, excellent, then the current patch is good enough. You're of course
> welcome
> to submit a v2 with fixed commit message and comments.
>
>
> >  >sure that it's really building correctly for the target?
> > My next submission is scipy and it relies on the host- version of this
> pkg (now
> > supposedly 2.8.1 if you merge patch #2).
> > And I just redid a test of the produced scipy binaries on my zedboard,
> they work
> > fine.
> > The problem to answer fully your question is that:
> > * no pkg currently depend on pybind
> > * my next submission depends on host-pybind (to be submitted after all
> the
> > fixing), not on target-pybind.
> > This is why I wanted to move this pkg to a host-only package, but Yann
> corrected
> > otherwise
>
>   You yourself submitted the pybind package about a year ago. What was it
> for
> then? Was it already for scipy? Was it just by accident that you submitted
> a
> target version instead of a host version?
>
>   Regards,
>   Arnout
>
> >
> > I will wait for you answer before submitting a V2 depending on what we
> decide
> >
> > Guillaume W. Bres
> > Software engineer
> > <guillaume.bressaix@gmail.com <mailto:guillaume.bressaix@gmail.com>>
> >
> >
> > Le lun. 6 déc. 2021 à 08:45, Arnout Vandecappelle <arnout@mind.be
> > <mailto:arnout@mind.be>> a écrit :
> >
> >        Hi Guillaume,
> >
> >        This is still looking fairly weird to me...
> >
> >     On 05/12/2021 21:47, guillaume.bressaix@gmail.com
> >     <mailto:guillaume.bressaix@gmail.com> wrote:
> >      > From: "Guillaume W. Bres" <guillaume.bressaix@gmail.com
> >     <mailto:guillaume.bressaix@gmail.com>>
> >      >
> >      > The python 'setup.py' script needs header files
> >      > in $(@D)/pybind11 to work since v2.6.1, and these files
> >      > are created by an internal minimalist cmake build.
> >      >
> >      > fixes
> >
> http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d
> >     <
> http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d
> >
> >
> >        Nitpick: to make it appear with the fixes tag in patchwork or in
> the summary
> >     that Peter makes, you have to format it like this:
> >
> >     Fixes:
> >
> http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d
> >     <
> http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d
> >
> >           http://...
> >
> >      > fixes
> >
> http://autobuild.buildroot.net/results/d0287b7f64f206b0f074908c5780a3632e0cb799
> >     <
> http://autobuild.buildroot.net/results/d0287b7f64f206b0f074908c5780a3632e0cb799
> >
> >      > fixes
> >
> http://autobuild.buildroot.net/results/27efb545a5a719a5581c8f746d3a3555ff4216ce
> >     <
> http://autobuild.buildroot.net/results/27efb545a5a719a5581c8f746d3a3555ff4216ce
> >
> >      > fixes
> >
> http://autobuild.buildroot.net/results/d2f0a0ad8f6c7178517df109e7d885dac9134c3a
> >     <
> http://autobuild.buildroot.net/results/d2f0a0ad8f6c7178517df109e7d885dac9134c3a
> >
> >      > fixes
> >
> http://autobuild.buildroot.net/results/b57e9a3279260dae4a590f9421238fcabb2f7cab
> >     <
> http://autobuild.buildroot.net/results/b57e9a3279260dae4a590f9421238fcabb2f7cab
> >
> >      > fixes
> >
> http://autobuild.buildroot.net/results/515e6f2fc6b5780260d98d6bb52b541ce4bf1afe
> >     <
> http://autobuild.buildroot.net/results/515e6f2fc6b5780260d98d6bb52b541ce4bf1afe
> >
> >      > fixes
> >
> http://autobuild.buildroot.net/results/d89c4ecc81222d4f80c951da2232d2e393fa1c69
> >     <
> http://autobuild.buildroot.net/results/d89c4ecc81222d4f80c951da2232d2e393fa1c69
> >
> >      >
> >      > Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com
> >     <mailto:guillaume.bressaix@gmail.com>>
> >      >
> >      > ---
> >      > This remains a python-package.
> >      >
> >      > 'python setup.py' actually hardcodes a system call to cmake,
> >      > which seems dirty at first.
> >      > Fortunately, if we have CMAKE ENV, all BR variables are retrieved.
> >
> >        I don't see CMAKE_ENV anywhere in Buildroot, or in this patch.
> >
> >        Also, I don't think there's any way to tell CMake about "all BR
> variables"
> >     other than passing a toolchainfile (with
> -DCMAKE_TOOLCHAIN_FILE=...). Are you
> >     sure that it's really building correctly for the target?
> >
> >
> >        Regards,
> >        Arnout
> >
> >
> >      > I think they made this cmake call to make setup.py self
> sufficient.
> >      >
> >      > ---
> >      >   package/python-pybind/python-pybind.mk <http://python-pybind.mk>
> | 6 ++++++
> >      >   1 file changed, 6 insertions(+)
> >      >
> >      > diff --git a/package/python-pybind/python-pybind.mk
> >     <http://python-pybind.mk> b/package/python-pybind/python-pybind.mk
> >     <http://python-pybind.mk>
> >      > index a6a1bdb976..080586a877 100644
> >      > --- a/package/python-pybind/python-pybind.mk <
> http://python-pybind.mk>
> >      > +++ b/package/python-pybind/python-pybind.mk <
> http://python-pybind.mk>
> >      > @@ -9,5 +9,11 @@ PYTHON_PYBIND_SITE = $(call
> >     github,pybind,pybind11,v$(PYTHON_PYBIND_VERSION))
> >      >   PYTHON_PYBIND_LICENSE = BSD-3-Clause
> >      >   PYTHON_PYBIND_LICENSE_FILES = LICENSE
> >      >   PYTHON_PYBIND_SETUP_TYPE = setuptools
> >      > +PYTHON_PYBIND_INSTALL_STAGING = YES
> >      > +
> >      > +# every single 'python setup.py' call actually calls cmake
> >      > +# to populate $(@D)/pybind11 with .h and build requirements.
> >      > +# If we have a HOST_CMAKE_ENV, then installation paths are
> properly defined
> >      > +PYTHON_PYBIND_DEPENDENCIES = host-cmake
> >      >
> >      >   $(eval $(python-package))
> >      >
> >
>

[-- Attachment #1.2: Type: text/html, Size: 13788 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/python-pybind: fix upgrade to version 2.6.1

[Arnout Vandecappelle]

On 06/12/2021 20:27, Guillaume Bres wrote:
> Arnout,
> I am submitting a revised version of these patches, please discard v1
> 
>  >What was it for then? Was it already for scipy?
> yep

  By the way, are you aware that there's an existing patch series [1] for adding 
scipy?

  Regards,
  Arnout


[1] https://patchwork.ozlabs.org/project/buildroot/list/?series=168992

> 
>  >  Was it just by accident that you submitted a target version instead of a 
> host version?
> I don't really know why I did so, but at the time I decided I would unlock the 
> host-pkg version in the scipy patch that requires it.
> Actually it still has to be done because we might fix the pkg today, but that 
> won't be enough for future dependencies
[snip]
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot