discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] 3.8.0.0-rc2 build from source on macOS


From: CEL
Subject: Re: [Discuss-gnuradio] 3.8.0.0-rc2 build from source on macOS
Date: Thu, 8 Aug 2019 13:11:53 +0000

Hi Emmanuel,

my Apple experience limits itself to using an iPod in the summer 2010
or so, but I hope I can still be of help. First of all: Which path are
you taking to build stuff? 

> - What is the proper/best/recommended UI framework to use?
> 
>    * Default build uses GTK, but it seems there is no 
> spectrum/oscilloscope/... virtual device available with this framework. 
> Am I wrong?

Kind of. GRC uses GTK as the UI which you use to build flow graphs.

The flow graphs themselves are not related to that UI.

So, mentally separate the signal processing design tool "GRC" from the
signal displaying tool "gr-qtgui". The first is python using GTK, the
second a mix of C++ and Python using Qt. The first generates a program
that sets up a GNU Radio flow graph and executes it, the second is used
in that flowgraph (potentially).

>    * WxWidget does not seem to be supported anymore. Am I correct?

Correct. gr-wxgui wasn't maintainable for us anymore, and after 4 years
of announcing that we're finally removing it :)

>    * (Py)QT seems to be hardcoded to use Python2, whereas 3.8 can be 
> build with Python3 as CMakeList.txt seems to check for Python2:
> 
>       gr-qtgui/CMakeLists.txt:find_package(PythonLibs 2)
> 
>     -- Configuring gnuradio-companion support...
>     --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>     --   Dependency ENABLE_PYTHON = ON
>     --   Dependency PYTHON_MIN_VER_FOUND = TRUE
>     --   Dependency PYYAML_FOUND = TRUE
>     --   Dependency MAKO_FOUND = TRUE
>     --   Dependency PYGI_FOUND = TRUE
>     --   Dependency GTK_GI_FOUND = TRUE
>     --   Dependency CAIRO_GI_FOUND = TRUE
>     --   Dependency PANGOCAIRO_GI_FOUND = TRUE
>     --   Dependency NUMPY_FOUND = TRUE
>     --   Enabling gnuradio-companion support.
>     --   Override with -DENABLE_GRC=ON/OFF
>     ...
>     -- Configuring gr-qtgui support...
>     --   Dependency Boost_FOUND = TRUE
>     --   Dependency QT_FOUND = 1
>     --   Dependency QWT_FOUND = TRUE
>     --   Dependency ENABLE_VOLK = ON
>     --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>     --   Dependency ENABLE_GR_FFT = ON
>     --   Dependency ENABLE_GR_FILTER = ON
>     --   Dependency PYTHONLIBS_FOUND = TRUE
>     --   Dependency PYQT5_FOUND = TRUE
>     --   Enabling gr-qtgui support.
>     --   Override with -DENABLE_GR_QTGUI=ON/OFF
> 

Ah! That might be a package naming problem. For example, on Fedora 30,
the package you want for python3 PyQt would be python3-PyQt5 and
python3-qt5-devel.

>    So I’m kind of lost here, any help/advice/URL would be greatly 
> appreciated.
>    I’ve successfully built the gnuradio-companion with GTK + PyQT + 
> QWT, but I’m not sure it can work as expected with this Python 2 
> thing. Can it?

So, two different things: making GRC work (GTK), and making gr-qtgui
(QT, PyQt, Qwt) work.

> 
>    How to know which framework is actually used, as it seems both GTK 
> and QT dependencies are successfully found?

Both, for different things.
>    Or does it mean the UI is using (Py)GTK, but some UI items rely on 
> QT? I’m kinda lost….

Hope I got you out of that confusion!

>    When QT support is not added, GRC accepts to drag and drop blocks, 
> but on the first attempt to interconnect two blocks, the UI gets lost, 
> zoom in, then crashes.

That's probably something else, as said, Qt isn't used in GRC. You
don't need Qt to have GRC, and you don't need GRC to get gr-qtgui.

>    When QT support is present, GRC fails even earlier when the first 
> block is dropped, with the following backtrace:
> 
>      $ gnuradio-companion
>      <<< Welcome to GNU Radio Companion 3.8.0.0-rc2 >>>
> 
>      Block paths:
>         /usr/local/Cellar/gnuradio/3.8.0.0-rc2/share/gnuradio/grc/blocks
>      Traceback (most recent call last):
>        File 
> "/usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/dist-packages/gnuradio/grc/gui/DrawingArea.py",
>  
> line 103, in     _handle_drag_data_received
>          self._flow_graph.add_new_block(selection_data.get_text(), 
> coords)
>        File 
> "/usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/dist-packages/gnuradio/grc/gui/canvas/flowgraph.py",
>  
> line 176, in     add_new_block
>          block.coordinate = coor
>      AttributeError: 'NoneType' object has no attribute 'coordinate'
> 

I'd call that a bug!
Can you tell us which blog you dragged onto the canvas, or does this
happen with all blocks?

Also: this is a clean install, right? There's no e.g. flowgraph.py
flying around anywhere else on your system where python might be
erratically picking it up?

Best regards,
Marcus

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]