[v6,3/3] GNURadio: new package

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

Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
---
Changes v5 -> v6:
* GNURADIO_SUPPORTS_IN_SOURCE_BUILD = no -> GNURADIO_SUPPORTS_IN_SOURCE_BUILD = NO
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

On 11/03/15 13:13, Gwenhael Goavec-Merou wrote:
> From: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
> 
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>

 Unfortunately I still have a few comments. But I think GNURadio is a really
useful package for buildroot (or vice versa :-).

> ---

[snip]
> 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)

 My CMake knowledge is a bit limited, but if boost's unit test framework is not
enabled and BUILD_TEST is, will this not give an error? For buildroot that's not
so relevant because we never enable BUILD_TEST, but for upstreaming it is.

> + 
> +     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

 Two tabs is enough for the continued indentation.

> +
[snip]
> 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

 If upstream only provides md5, we usually add a locally-calculated sha256.

> 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

 This comment is redundant, the variable explains it all.

> +GNURADIO_SUPPORTS_IN_SOURCE_BUILD = NO
> +
> +# host-python-cheetah is needed for volk to compile
> +GNURADIO_DEPENDENCIES = \
> +		host-python-cheetah \
> +		host-swig \

 Isn't host-swig only needed when python is enabled? Or does volk also require it?

> +		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"

 Not all armv7 actually support NEON, so this should also be in the HAS_NEON
condition. So something like:

# 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)$(BR2_ARM_CPU_HAS_NEON),yy)
GNURADIO_CONF_OPTS += -DCMAKE_C_FLAGS="-march=armv7-a"
endif

> +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

 I don't find anything that looks like this CMake variable in the source... Are
you sure it does anything?


 Regards,
 Arnout


> +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))
>

On Thu, 12 Mar 2015 00:14:44 +0100
Arnout Vandecappelle <arnout@mind.be> wrote:

> On 11/03/15 13:13, Gwenhael Goavec-Merou wrote:
> > From: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
> > 
> > Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
> 
>  Unfortunately I still have a few comments. But I think GNURadio is a really
> useful package for buildroot (or vice versa :-).
> 
> > ---
[snip]
> > +# host-python-cheetah is needed for volk to compile
> > +GNURADIO_DEPENDENCIES = \
> > +		host-python-cheetah \
> > +		host-swig \
> 
>  Isn't host-swig only needed when python is enabled? Or does volk also require it?
>
(host-)swig is only needed for the compilation. At runtime is no more needed.
>
[snip]
> > +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
> 
>  I don't find anything that looks like this CMake variable in the source... Are
> you sure it does anything?
> 
Yes, it disable all hf/neon optimization. If it is use unconditionnaly the
previous WA is not needed but volk is not optimized for hf/neon.
> 
>  Regards,
>  Arnout
> 
Regards,

Gwen