From: "Guillaume W. Bres" <redacted>
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 <redacted>
---
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
From: "Guillaume W. Bres" <redacted>
Signed-off-by: Guillaume W. Bres <redacted>
---
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
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" <redacted>
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 <redacted>
---
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
quoted hunk
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
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
[off-list ref]
Le lun. 6 déc. 2021 à 08:45, Arnout Vandecappelle [off-list ref] a écrit :
Hi Guillaume,
This is still looking fairly weird to me...
On 05/12/2021 21:47, guillaume.bressaix@gmail.com wrote:
quoted
From: "Guillaume W. Bres" <redacted>
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://...
quoted
fixes
http://autobuild.buildroot.net/results/d0287b7f64f206b0f074908c5780a3632e0cb799
quoted
fixes
http://autobuild.buildroot.net/results/27efb545a5a719a5581c8f746d3a3555ff4216ce
quoted
fixes
http://autobuild.buildroot.net/results/d2f0a0ad8f6c7178517df109e7d885dac9134c3a
quoted
fixes
http://autobuild.buildroot.net/results/b57e9a3279260dae4a590f9421238fcabb2f7cab
quoted
fixes
http://autobuild.buildroot.net/results/515e6f2fc6b5780260d98d6bb52b541ce4bf1afe
quoted
fixes
http://autobuild.buildroot.net/results/d89c4ecc81222d4f80c951da2232d2e393fa1c69
quoted
Signed-off-by: Guillaume W. Bres <redacted>
---
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
quoted
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
quoted
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))
quoted
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
quoted
+PYTHON_PYBIND_DEPENDENCIES = host-cmake
$(eval $(python-package))
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
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
[off-list ref]
Le lun. 6 déc. 2021 à 14:20, Arnout Vandecappelle [off-list ref] a écrit :
On 06/12/2021 13:39, Guillaume Bres wrote:
quoted
Arnout,
thanks for the quick review
>Nitpick: to make it appear with the fixes tag in patchwork or in the
summary
quoted
>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,
quoted
especially those, because they are to remain visible to clarify things
in case
quoted
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"
quoted
>other than passing a toolchainfile (with -DCMAKE_TOOLCHAIN_FILE=...).
Are you
quoted
>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.
quoted
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
quoted
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
quoted
conversation, as I ran into this fix unexpectedly.
I actually works (tested on 2 platforms), the intrinsic build failure is
fixed.
quoted
With the cmake-package option, that I also inquired intensively, I never
get a
quoted
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.
quoted
>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
quoted
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
quoted
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
quoted
fixing), not on target-pybind.
This is why I wanted to move this pkg to a host-only package, but Yann
corrected
quoted
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
quoted
I will wait for you answer before submitting a V2 depending on what we
decide
quoted
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
quoted
<
http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d
quoted
Nitpick: to make it appear with the fixes tag in patchwork or in
the summary
quoted
that Peter makes, you have to format it like this:
Fixes:
http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d
quoted
<
http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d
quoted
http://...
> fixes
http://autobuild.buildroot.net/results/d0287b7f64f206b0f074908c5780a3632e0cb799
quoted
<
http://autobuild.buildroot.net/results/d0287b7f64f206b0f074908c5780a3632e0cb799
quoted
> fixes
http://autobuild.buildroot.net/results/27efb545a5a719a5581c8f746d3a3555ff4216ce
quoted
<
http://autobuild.buildroot.net/results/27efb545a5a719a5581c8f746d3a3555ff4216ce
quoted
> fixes
http://autobuild.buildroot.net/results/d2f0a0ad8f6c7178517df109e7d885dac9134c3a
quoted
<
http://autobuild.buildroot.net/results/d2f0a0ad8f6c7178517df109e7d885dac9134c3a
quoted
> fixes
http://autobuild.buildroot.net/results/b57e9a3279260dae4a590f9421238fcabb2f7cab
quoted
<
http://autobuild.buildroot.net/results/b57e9a3279260dae4a590f9421238fcabb2f7cab
quoted
> fixes
http://autobuild.buildroot.net/results/515e6f2fc6b5780260d98d6bb52b541ce4bf1afe
quoted
<
http://autobuild.buildroot.net/results/515e6f2fc6b5780260d98d6bb52b541ce4bf1afe
quoted
> fixes
http://autobuild.buildroot.net/results/d89c4ecc81222d4f80c951da2232d2e393fa1c69
quoted
<
http://autobuild.buildroot.net/results/d89c4ecc81222d4f80c951da2232d2e393fa1c69
quoted
>
> 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"
quoted
other than passing a toolchainfile (with
-DCMAKE_TOOLCHAIN_FILE=...). Are you
quoted
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.
quoted
>
> ---
> package/python-pybind/python-pybind.mk <http://python-pybind.mk>
| 6 ++++++
quoted
> 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>
quoted
> +++ b/package/python-pybind/python-pybind.mk <
http://python-pybind.mk>
quoted
> @@ -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
quoted
> +PYTHON_PYBIND_DEPENDENCIES = host-cmake
>
> $(eval $(python-package))
>
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