[Buildroot] [PATCH v5 1/3] pkg-cmake: allow to build package in a subdirectory

[Buildroot] [PATCH v5 1/3] pkg-cmake: allow to build package in a subdirectory

[Samuel Martin]

Hi Gwenhael,

On Tue, Mar 10, 2015 at 7:24 PM, Gwenhael Goavec-Merou
<gwenj@trabucayre.com> wrote:
> From: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
>
> For some cmake based packages, like GNURadio, it's forbidden to do the
> compilation directly in the sources directory. This patch add a new
> variable to specify, if needed, the name of a sub-directory used to compile.
>
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
> ---
> Changes v4 -> v5:
>  * Instead of overloading BUILDDIR uses a variable to set if package is compiled
>    in-source-tree or not
>  * update again manual
> Changes v2 -> v3:
>  * Update docs to add detail about LIBFOO_BUILDDIR
> Changes v1 -> v2:
>  * Allow to overload $(2)_BUILDDIR instead of adding a new variable and test
> ---
>  docs/manual/adding-packages-cmake.txt |  3 +++
>  package/pkg-cmake.mk                  | 11 +++++++++--
>  2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/docs/manual/adding-packages-cmake.txt b/docs/manual/adding-packages-cmake.txt
> index d92b209..0d4f2fa 100644
> --- a/docs/manual/adding-packages-cmake.txt
> +++ b/docs/manual/adding-packages-cmake.txt
> @@ -146,3 +146,6 @@ possible to customize what is done in any particular step:
>    +LIBFOO_CONFIGURE_CMDS+ variable, it will be used instead of the
>    default CMake one. However, using this method should be restricted
>    to very specific cases. Do not use it in the general case.
> +
> +* By adding +LIBFOO_SUPPORTS_IN_SOURCE_BUILD = no+ when a package
> +  prevents doing an in-source-tree build.
> diff --git a/package/pkg-cmake.mk b/package/pkg-cmake.mk
> index 2404c40..9de21b5 100644
> --- a/package/pkg-cmake.mk
> +++ b/package/pkg-cmake.mk
> @@ -61,7 +61,12 @@ $(2)_INSTALL_STAGING_OPTS    ?= DESTDIR=$$(STAGING_DIR) install
>  $(2)_INSTALL_TARGET_OPTS               ?= DESTDIR=$$(TARGET_DIR) install
>
>  $(2)_SRCDIR                    = $$($(2)_DIR)/$$($(2)_SUBDIR)
> +
> +ifeq ($$($(2)_SUPPORTS_IN_SOURCE_BUILD), no)
s/, no/,no/

s/$(2)/$(3)/
When in-srctree build is forbidden, it is for both target and host
package, so there is no need for having
HOST_FOO_SUPPORTS_IN_SOURCE_BUILD set when
FOO_SUPPORTS_IN_SOURCE_BUILD is already set.

> +$(2)_BUILDDIR                  = $$($(2)_SRCDIR)/buildroot-build
> +else
>  $(2)_BUILDDIR                  = $$($(2)_SRCDIR)
> +endif
>
>  #
>  # Configure step. Only define it if not already defined by the package
> @@ -73,7 +78,8 @@ ifeq ($(4),target)
>
>  # Configure package for target
>  define $(2)_CONFIGURE_CMDS
> -       (cd $$($$(PKG)_BUILDDIR) && \
> +       (mkdir -p $$($$(PKG)_BUILDDIR) && \
> +       cd $$($$(PKG)_BUILDDIR) && \
>         rm -f CMakeCache.txt && \
>         PATH=$$(BR_PATH) \
>         $$($$(PKG)_CONF_ENV) $$(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR) \
> @@ -98,7 +104,8 @@ else
>
>  # Configure package for host
>  define $(2)_CONFIGURE_CMDS
> -       (cd $$($$(PKG)_BUILDDIR) && \
> +       (mkdir -p $$($$(PKG)_BUILDDIR) && \
> +       cd $$($$(PKG)_BUILDDIR) && \
>         rm -f CMakeCache.txt && \
>         PATH=$$(BR_PATH) \
>         $$(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR) \
> --
> 2.0.5
>

Regards,

-- 
Samuel

[Buildroot] [PATCH v5 1/3] pkg-cmake: allow to build package in a subdirectory

[Thomas Petazzoni]

Dear Samuel Martin,

On Tue, 10 Mar 2015 18:35:21 +0100, Samuel Martin wrote:

> > +ifeq ($$($(2)_SUPPORTS_IN_SOURCE_BUILD), no)
> s/, no/,no/

Actually it should be 'NO' and not 'no'. All other package infra
variables have upper-case values.

I know I suggested the SUPPORTS_IN_SOURCE_BUILD name, but what worries
me a bit is that if one day we want to make the default to build things
out of tree, a variable named <pkg>_SUPPORTS_IN_SOURCE_BUILD would not
make much sense anymore. It would have to be named
<pkg>_REQUIRES_IN_SOURCE_BUILD, set to NO by default in the package
infra, and that can be overridden to YES by those packages that don't
support out of tree build.

So I'm not sure what to do know. Go with <pkg>_SUPPORTS_IN_SOURCE_BUILD
for the moment, and change that when time comes?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v5 1/3] pkg-cmake: allow to build package in a subdirectory

[Gwenhael Goavec-Merou]

From: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>

For some cmake based packages, like GNURadio, it's forbidden to do the
compilation directly in the sources directory. This patch add a new 
variable to specify, if needed, the name of a sub-directory used to compile.

Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
---
Changes v4 -> v5:
 * Instead of overloading BUILDDIR uses a variable to set if package is compiled
   in-source-tree or not
 * update again manual
Changes v2 -> v3:
 * Update docs to add detail about LIBFOO_BUILDDIR
Changes v1 -> v2:
 * Allow to overload $(2)_BUILDDIR instead of adding a new variable and test
---
 docs/manual/adding-packages-cmake.txt |  3 +++
 package/pkg-cmake.mk                  | 11 +++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/docs/manual/adding-packages-cmake.txt b/docs/manual/adding-packages-cmake.txt
index d92b209..0d4f2fa 100644
--- a/docs/manual/adding-packages-cmake.txt
+++ b/docs/manual/adding-packages-cmake.txt
@@ -146,3 +146,6 @@ possible to customize what is done in any particular step:
   +LIBFOO_CONFIGURE_CMDS+ variable, it will be used instead of the
   default CMake one. However, using this method should be restricted
   to very specific cases. Do not use it in the general case.
+
+* By adding +LIBFOO_SUPPORTS_IN_SOURCE_BUILD = no+ when a package
+  prevents doing an in-source-tree build.
diff --git a/package/pkg-cmake.mk b/package/pkg-cmake.mk
index 2404c40..9de21b5 100644
--- a/package/pkg-cmake.mk
+++ b/package/pkg-cmake.mk
@@ -61,7 +61,12 @@ $(2)_INSTALL_STAGING_OPTS	?= DESTDIR=$$(STAGING_DIR) install
 $(2)_INSTALL_TARGET_OPTS		?= DESTDIR=$$(TARGET_DIR) install
 
 $(2)_SRCDIR			= $$($(2)_DIR)/$$($(2)_SUBDIR)
+
+ifeq ($$($(2)_SUPPORTS_IN_SOURCE_BUILD), no)
+$(2)_BUILDDIR			= $$($(2)_SRCDIR)/buildroot-build
+else
 $(2)_BUILDDIR			= $$($(2)_SRCDIR)
+endif
 
 #
 # Configure step. Only define it if not already defined by the package
@@ -73,7 +78,8 @@ ifeq ($(4),target)
 
 # Configure package for target
 define $(2)_CONFIGURE_CMDS
-	(cd $$($$(PKG)_BUILDDIR) && \
+	(mkdir -p $$($$(PKG)_BUILDDIR) && \
+	cd $$($$(PKG)_BUILDDIR) && \
 	rm -f CMakeCache.txt && \
 	PATH=$$(BR_PATH) \
 	$$($$(PKG)_CONF_ENV) $$(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR) \
@@ -98,7 +104,8 @@ else
 
 # Configure package for host
 define $(2)_CONFIGURE_CMDS
-	(cd $$($$(PKG)_BUILDDIR) && \
+	(mkdir -p $$($$(PKG)_BUILDDIR) && \
+	cd $$($$(PKG)_BUILDDIR) && \
 	rm -f CMakeCache.txt && \
 	PATH=$$(BR_PATH) \
 	$$(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR) \
-- 
2.0.5

[Buildroot] [PATCH v5 2/3] python-cheetah: add host-package support

[Gwenhael Goavec-Merou]

From: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>

Some packages, like GNURadio for VOLK, needs cheetah on host at buildtime.

Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
---
Changes v3 -> v4:
 * use HOST_PYTHON_CHEETAH_DEPENDENCIES instead of PYTHON_CHEETAH_DEPENDENCIES
 * suppress '+' for dependency definition
---
 package/python-cheetah/python-cheetah.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/python-cheetah/python-cheetah.mk b/package/python-cheetah/python-cheetah.mk
index 08076b5..3155951 100644
--- a/package/python-cheetah/python-cheetah.mk
+++ b/package/python-cheetah/python-cheetah.mk
@@ -9,5 +9,7 @@ PYTHON_CHEETAH_SOURCE = Cheetah-$(PYTHON_CHEETAH_VERSION).tar.gz
 PYTHON_CHEETAH_SITE = http://pypi.python.org/packages/source/C/Cheetah
 PYTHON_CHEETAH_LICENSE = MIT
 PYTHON_CHEETAH_SETUP_TYPE = setuptools
+HOST_PYTHON_CHEETAH_DEPENDENCIES = host-python-markdown
 
 $(eval $(python-package))
+$(eval $(host-python-package))
-- 
2.0.5

[Buildroot] [PATCH v5 3/3] GNURadio: new package

[Gwenhael Goavec-Merou]

From: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>

Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
---
Changes v4 -> v5:
* GNURadio -> gnuradio.
* help for all options.
* rename patch, add signed-off and a comment.
* dependencies comment.
* typo. 
* better workaround to avoid compile fails when neon is enabled.
* indentation.
* better options handlings.
Changes v2 -> v3:
* move comment at the beginning of the file.
* add a patch to suppress boost-test dependency.
* move python dependencies in the specific option.
* use stable archive instead of git.
* add hook specific for ARM for using neon if available (without this hook volk
  fails to build).
Changes v1 -> v2:
* overload _BUILDDIR variable to specify build directory
---
 package/Config.in                                  |  1 +
 .../0001-suppress-boost_unitest-detection.patch    | 32 ++++++++++++
 package/gnuradio/Config.in                         | 46 +++++++++++++++++
 package/gnuradio/gnuradio.hash                     |  2 +
 package/gnuradio/gnuradio.mk                       | 59 ++++++++++++++++++++++
 5 files changed, 140 insertions(+)
 create mode 100644 package/gnuradio/0001-suppress-boost_unitest-detection.patch
 create mode 100644 package/gnuradio/Config.in
 create mode 100644 package/gnuradio/gnuradio.hash
 create mode 100644 package/gnuradio/gnuradio.mk

diff --git a/package/Config.in b/package/Config.in
index cab9382..5d9e540 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -1043,6 +1043,7 @@ menu "Miscellaneous"
 	source "package/clamav/Config.in"
 	source "package/collectd/Config.in"
 	source "package/empty/Config.in"
+	source "package/gnuradio/Config.in"
 	source "package/googlefontdirectory/Config.in"
 	source "package/haveged/Config.in"
 	source "package/mcrypt/Config.in"
diff --git a/package/gnuradio/0001-suppress-boost_unitest-detection.patch b/package/gnuradio/0001-suppress-boost_unitest-detection.patch
new file mode 100644
index 0000000..ab8411b
--- /dev/null
+++ b/package/gnuradio/0001-suppress-boost_unitest-detection.patch
@@ -0,0 +1,32 @@
+By default, the boost test option is mandatory for build environment
+detection. 
+This patch suppress this dependency and allows the test part only if
+build_test is enabled at the Buildroot level.
+
+Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
+---
+Index: gnuradio-3.7.5/volk/cmake/VolkBoost.cmake
+===================================================================
+--- gnuradio-3.7.5.orig/volk/cmake/VolkBoost.cmake
++++ gnuradio-3.7.5/volk/cmake/VolkBoost.cmake
+@@ -29,7 +29,6 @@ set(__INCLUDED_VOLK_BOOST_CMAKE TRUE)
+ set(BOOST_REQUIRED_COMPONENTS
+     filesystem
+     system
+-    unit_test_framework
+     program_options
+ )
+ 
+Index: gnuradio-3.7.5/volk/lib/CMakeLists.txt
+===================================================================
+--- gnuradio-3.7.5.orig/volk/lib/CMakeLists.txt
++++ gnuradio-3.7.5/volk/lib/CMakeLists.txt
+@@ -541,7 +541,7 @@ endif(ENABLE_STATIC_LIBS)
+ ########################################################################
+ 
+ 
+-if(Boost_FOUND)
++if(Boost_FOUND AND BUILD_TEST)
+ 
+     set_source_files_properties(
+         ${CMAKE_CURRENT_SOURCE_DIR}/testqa.cc PROPERTIES
diff --git a/package/gnuradio/Config.in b/package/gnuradio/Config.in
new file mode 100644
index 0000000..a95c704
--- /dev/null
+++ b/package/gnuradio/Config.in
@@ -0,0 +1,46 @@
+comment "gnuradio needs a toolchain w/ C++, IPV6, threads, largefile, wchar"
+	depends on BR2_USE_MMU
+	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR || \
+			!BR2_TOOLCHAIN_HAS_THREADS || !BR2_LARGEFILE || \
+			!BR2_INET_IPV6
+
+config BR2_PACKAGE_GNURADIO
+	bool "gnuradio"
+	depends on BR2_INET_IPV6 # boost
+	depends on BR2_INSTALL_LIBSTDCPP
+	depends on BR2_LARGEFILE # boost
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	depends on BR2_USE_MMU # use fork()
+	depends on BR2_USE_WCHAR # boost
+	select BR2_PACKAGE_BOOST
+	select BR2_PACKAGE_BOOST_DATE_TIME
+	select BR2_PACKAGE_BOOST_FILESYSTEM
+	select BR2_PACKAGE_BOOST_PROGRAM_OPTIONS
+	select BR2_PACKAGE_BOOST_SYSTEM
+	select BR2_PACKAGE_BOOST_THREAD
+	help
+	  GNU Radio is a free & open-source software development toolkit
+	  that provides signal processing blocks to implement software
+	  radios. It can be used with readily-available low-cost external
+	  RF hardware to create software-defined radios, or without
+	  hardware in a simulation-like environment. It is widely used in
+	  hobbyist, academic and commercial environments to support both
+	  wireless communications research and real-world radio systems.
+
+	  http://gnuradio.org/
+
+if BR2_PACKAGE_GNURADIO
+
+config BR2_PACKAGE_GNURADIO_BLOCKS
+	bool "blocks support"
+	help
+	  GNU Radio basic block library
+
+config BR2_PACKAGE_GNURADIO_PYTHON
+	bool "python support"
+	select BR2_PACKAGE_BOOST_PYTHON
+	select BR2_PACKAGE_PYTHON
+	help
+	  Enable python component
+
+endif
diff --git a/package/gnuradio/gnuradio.hash b/package/gnuradio/gnuradio.hash
new file mode 100644
index 0000000..a25b466
--- /dev/null
+++ b/package/gnuradio/gnuradio.hash
@@ -0,0 +1,2 @@
+# From http://gnuradio.org/redmine/projects/gnuradio/files
+md5	b4a917a548f41ce25c6c88f9bc864bca	gnuradio-3.7.5.tar.gz
diff --git a/package/gnuradio/gnuradio.mk b/package/gnuradio/gnuradio.mk
new file mode 100644
index 0000000..e503911
--- /dev/null
+++ b/package/gnuradio/gnuradio.mk
@@ -0,0 +1,59 @@
+################################################################################
+#
+# gnuradio
+#
+################################################################################
+
+GNURADIO_VERSION = 3.7.5
+GNURADIO_SITE = http://gnuradio.org/redmine/attachments/download/792
+GNURADIO_LICENSE = GPLv3+
+GNURADIO_LICENSE_FILES = COPYING
+
+# gnuradio prevents doing an in-source-tree build
+GNURADIO_SUPPORTS_IN_SOURCE_BUILD = no
+
+# host-python-cheetah is needed for volk to compile
+GNURADIO_DEPENDENCIES = \
+		host-python-cheetah \
+		host-swig \
+		boost
+
+GNURADIO_CONF_OPTS = \
+		-DENABLE_DEFAULT=OFF \
+		-DENABLE_VOLK=ON \
+		-DENABLE_GNURADIO_RUNTIME=ON
+
+#For third-party blocks,  the gnuradio libraries are mandatory at 
+# compile time.
+GNURADIO_INSTALL_STAGING = YES
+
+# Yes, this is silly, because -march is already known by the compiler
+# with the internal toolchain, and passed by the external wrapper for
+# external toolchains. Nonetheless, gnuradio does some matching on the
+# CFLAGS to decide whether to build the NEON functions or not, and
+# wants to see the string 'armv7' in the CFLAGS.
+ifeq ($(BR2_ARM_CPU_ARMV7A),y)
+GNURADIO_CONF_OPTS += -DCMAKE_C_FLAGS="-march=armv7-a"
+endif
+
+# As soon as -mfpu=neon is supported by the compiler, gnuradio will try
+# to use it. But having NEON support in the compiler doesn't necessarily
+# mean we have NEON support in our CPU.
+ifeq ($(BR2_ARM_CPU_HAS_NEON),)
+GNURADIO_CONF_OPTS += -Dhave_mfpu_neon=0
+endif
+
+ifeq ($(BR2_PACKAGE_GNURADIO_BLOCKS),y)
+GNURADIO_CONF_OPTS += -DENABLE_GR_BLOCKS=ON
+else
+GNURADIO_CONF_OPTS += -DENABLE_GR_BLOCKS=OFF
+endif
+
+ifeq ($(BR2_PACKAGE_GNURADIO_PYTHON),y)
+GNURADIO_DEPENDENCIES += python
+GNURADIO_CONF_OPTS += -DENABLE_PYTHON=ON
+else
+GNURADIO_CONF_OPTS += -DENABLE_PYTHON=OFF
+endif
+
+$(eval $(cmake-package))
-- 
2.0.5

[Buildroot] [PATCH v5 1/3] pkg-cmake: allow to build package in a subdirectory

[Arnout Vandecappelle]

On 10/03/15 18:56, Thomas Petazzoni wrote:
> Dear Samuel Martin,
> 
> On Tue, 10 Mar 2015 18:35:21 +0100, Samuel Martin wrote:
> 
>>> +ifeq ($$($(2)_SUPPORTS_IN_SOURCE_BUILD), no)
>> s/, no/,no/
> 
> Actually it should be 'NO' and not 'no'. All other package infra
> variables have upper-case values.
> 
> I know I suggested the SUPPORTS_IN_SOURCE_BUILD name, but what worries
> me a bit is that if one day we want to make the default to build things
> out of tree, a variable named <pkg>_SUPPORTS_IN_SOURCE_BUILD would not
> make much sense anymore. It would have to be named
> <pkg>_REQUIRES_IN_SOURCE_BUILD, set to NO by default in the package
> infra, and that can be overridden to YES by those packages that don't
> support out of tree build.
> 
> So I'm not sure what to do know. Go with <pkg>_SUPPORTS_IN_SOURCE_BUILD
> for the moment, and change that when time comes?

 I'm all for building in a subirectory by default and only do it directly in the
tree when necessary.

 And in fact, I would not even introduce the _REQUIRES_IN_SOURCE_BUILD variable
until it is proven to be necessary. BTW, Thomas, did you introduce something
like that in your out-of-source-build branch?


 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH v5 1/3] pkg-cmake: allow to build package in a subdirectory

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Tue, 10 Mar 2015 22:43:10 +0100, Arnout Vandecappelle wrote:

>  I'm all for building in a subirectory by default and only do it directly in the
> tree when necessary.
> 
>  And in fact, I would not even introduce the _REQUIRES_IN_SOURCE_BUILD variable
> until it is proven to be necessary. BTW, Thomas, did you introduce something
> like that in your out-of-source-build branch?

Yes, I did have a flag that allows a package to say "I support
out-of-tree build". It defaulted to "NO" in generic-package, and to
"YES" in autotools-package and cmake-package, but can be overridden by
individual packages. For example, 'linux' can support out of tree build
even though it's a generic-package (well, now a kconfig-package), or an
autotools package may not support out of tree due to stupidities done
by the upstream developer.

However, this branch is now very old, and was far from being ready.

I really would like to put the smallest amount of work on Gwenhael
shoulders: I don't want to ask him, as a prerequisite of getting
gnuradio merged, to do some major surgery work deep in our package
infrastructure. So can we settle on a temporary solution that works for
gnuradio and is acceptable, and implement the grand plan of doing full
out of tree build at some later point?

Cheers,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v5 2/3] python-cheetah: add host-package support

[Arnout Vandecappelle]

On 10/03/15 19:24, Gwenhael Goavec-Merou wrote:
> From: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
> 
> Some packages, like GNURadio for VOLK, needs cheetah on host at buildtime.
> 
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
> ---
> Changes v3 -> v4:
>  * use HOST_PYTHON_CHEETAH_DEPENDENCIES instead of PYTHON_CHEETAH_DEPENDENCIES
>  * suppress '+' for dependency definition
> ---
>  package/python-cheetah/python-cheetah.mk | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/package/python-cheetah/python-cheetah.mk b/package/python-cheetah/python-cheetah.mk
> index 08076b5..3155951 100644
> --- a/package/python-cheetah/python-cheetah.mk
> +++ b/package/python-cheetah/python-cheetah.mk
> @@ -9,5 +9,7 @@ PYTHON_CHEETAH_SOURCE = Cheetah-$(PYTHON_CHEETAH_VERSION).tar.gz
>  PYTHON_CHEETAH_SITE = http://pypi.python.org/packages/source/C/Cheetah
>  PYTHON_CHEETAH_LICENSE = MIT
>  PYTHON_CHEETAH_SETUP_TYPE = setuptools
> +HOST_PYTHON_CHEETAH_DEPENDENCIES = host-python-markdown

 This should probably carry a comment to remember what you explained in an
earlier mail, e.g.:

# Runtime dependency on markdown is not expressed in Config.in for host package

and perhaps a fuller explanation in the commit log (explaining that setuptools
will download it if it can't be found).



 BTW, Thomas, when you committed python-cheetah you removed the runtime
dependency on markdown because there are some examples you can run without
markdown. Is that the way we work? The cheetah package itself declares a
dependency on markdown because one of its classes (Filters.Markdown) uses it. Of
course, as long as you don't use that particular filter, there won't be a
problem. But it feels weird to me that we remove a dependency that is claimed by
a package, unless there is a good reason for it (and I don't count saving 260K
of .pyc files as a good enough reason).


 Regards,
 Arnout

>  
>  $(eval $(python-package))
> +$(eval $(host-python-package))
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH v5 2/3] python-cheetah: add host-package support

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Tue, 10 Mar 2015 23:39:31 +0100, Arnout Vandecappelle wrote:

>  This should probably carry a comment to remember what you explained in an
> earlier mail, e.g.:
> 
> # Runtime dependency on markdown is not expressed in Config.in for host package
> 
> and perhaps a fuller explanation in the commit log (explaining that setuptools
> will download it if it can't be found).

Agreed. All those "unusual" dependencies should have a comment in
the .mk file.

>  BTW, Thomas, when you committed python-cheetah you removed the runtime
> dependency on markdown because there are some examples you can run without
> markdown. Is that the way we work? The cheetah package itself declares a
> dependency on markdown because one of its classes (Filters.Markdown) uses it. Of
> course, as long as you don't use that particular filter, there won't be a
> problem. But it feels weird to me that we remove a dependency that is claimed by
> a package, unless there is a good reason for it (and I don't count saving 260K
> of .pyc files as a good enough reason).

"Way we work" is fairly loosely defined when it comes to interpreted
languages and more-or-less optional dependencies :-)

Should python-cheetah select all the possible dependencies it may use
for all its filters, or should it leave this responsibility to the
Buildroot user ? Not easy to decide.

Since the dependency was apparently not strictly needed, and there was
(as far as I remember) no comment justifying the dependency, it seemed
natural to me to remove this dependency. That being said, I wouldn't be
offended at all if we decide to re-introduce the dependency, provided a
comment indicating why we're adding this not-really mandatory
dependency.

Cheers,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v5 2/3] python-cheetah: add host-package support

[Arnout Vandecappelle]

 Note to Gwenhael (removed from Cc): the discussion below is no longer relevant
for your patch.

On 10/03/15 23:47, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
> 
> On Tue, 10 Mar 2015 23:39:31 +0100, Arnout Vandecappelle wrote:

[snip]

>>  BTW, Thomas, when you committed python-cheetah you removed the runtime
>> dependency on markdown because there are some examples you can run without
>> markdown. Is that the way we work? The cheetah package itself declares a
>> dependency on markdown because one of its classes (Filters.Markdown) uses it. Of
>> course, as long as you don't use that particular filter, there won't be a
>> problem. But it feels weird to me that we remove a dependency that is claimed by
>> a package, unless there is a good reason for it (and I don't count saving 260K
>> of .pyc files as a good enough reason).
> 
> "Way we work" is fairly loosely defined when it comes to interpreted
> languages and more-or-less optional dependencies :-)
> 
> Should python-cheetah select all the possible dependencies it may use
> for all its filters, or should it leave this responsibility to the
> Buildroot user ? Not easy to decide.

 For me, the acid test is what the package declares itself.
Cheetah.egg-info/requires.txt says Markdown >= 2.0.1
For perl packages, we trust whatever dependencies the package declares. If we
would have a scancpan-like script for pypi, the dependency would be there.

> 
> Since the dependency was apparently not strictly needed, and there was
> (as far as I remember) no comment justifying the dependency, it seemed
> natural to me to remove this dependency. That being said, I wouldn't be
> offended at all if we decide to re-introduce the dependency, provided a
> comment indicating why we're adding this not-really mandatory
> dependency.

 On the other hand, as long as the lack of dependency is not bothering anyone,
we can leave it as it is :-) The purpose of discussion is what should be the
guiding principle for future python packages. My proposal is: follow the egg info.


 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH v5 2/3] python-cheetah: add host-package support

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >  On the other hand, as long as the lack of dependency is not bothering anyone,
 > we can leave it as it is :-) The purpose of discussion is what should be the
 > guiding principle for future python packages. My proposal is: follow the egg info.

Sounds sensible to me.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v5 2/3] python-cheetah: add host-package support

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Wed, 11 Mar 2015 00:02:29 +0100, Arnout Vandecappelle wrote:

>  For me, the acid test is what the package declares itself.
> Cheetah.egg-info/requires.txt says Markdown >= 2.0.1
> For perl packages, we trust whatever dependencies the package declares. If we
> would have a scancpan-like script for pypi, the dependency would be there.

I actually did start such a script at some point :-)

>  On the other hand, as long as the lack of dependency is not bothering anyone,
> we can leave it as it is :-) The purpose of discussion is what should be the
> guiding principle for future python packages. My proposal is: follow the egg info.

I'm fine with that.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com