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

[Michael Dickens]

Hi Emmanuel - I'm the GR OSX "expert" (LOL), as I do a lot of testing and 
verification and development on OSX (various versions). I'm happy to help as 
best I can. It might be that your issue is a generic GR bug. Let's take this 
discussion off-list & see what we can work out. If there's something relevant 
we can report back to the list and/or create a GR issue for it. - MLD

On Thu, Aug 8, 2019, at 10:02 AM, Emmanuel Blot wrote:
> Hi Marcus,
> 
> > 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?
> 
> I’m using Homebrew (https://brew.sh) to build *nix applications on 
> macOS.
> It is nice to have a controlled build environment.
> 
> To build GR 3.0.0.8-rc2, I’m using the default Apple compiler:
> 
> $ cc --version
> Apple LLVM version 10.0.1 (clang-1001.0.46.4)
> Target: x86_64-apple-darwin18.7.0
> Thread model: posix
> 
> and the following major dependencies:
> 
> cmake 3.15.2
> ninja 1.9.0
> swig 4.0.0
> python 3.7.4
> pyqt 5.10.1
> qwt 6.1.4
> qt 5.13.0
> 
> For PyGTK, I’m not sure which version is actually used.
> 
> >>> import gi
> >>> gi.version_info
> (3, 32, 2)
> 
> but PyGTK2 was also installed.
> 
> Let me know if there is a good/better way to check this point.
> 
> Less relevant I believe:
> 
> adwaita-icon-theme 3.32.0
> doxygen 1.8.15
> pkg-config 0.29.2
> sphinx 2.1.2
> boost 1.70.0
> fftw 3.3.8_1
> gsl 2.5
> numpy 1.16.4
> portaudio 19.6.0
> libyaml 0.2.2
> mpir 3.0.0
> uhd 3.14.1.0
> zeromq 4.3.2
> freeglut 3.0.0
> log4cpp 1.1.3
> + all sub-dependencies + all Python modules :P
> 
> GR is therefore built with CMake/Ninja, from an out of source build.
> I can post the build log if it can help.
> 
> I’m not sure I answer your question about the build path I take, 
> please let me know.
> 
> > 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.
> 
> I think on QT side this is correct (QT5), but I’m not sure how to 
> check which actual GTK version is actually used.
> I do develop on the same host with PyGTK3.
> 
> I removed GTK2 and pygtk (for Py2) packages as they were only used for 
> the previous GR 3.7 series on my host - it did not help up to now.
> 
> > So, two different things: making GRC work (GTK), and making gr-qtgui
> > (QT, PyQt, Qwt) work.
> 
> Ok, got it.
> 
> > Hope I got you out of that confusion!
> 
> Yes. Thanks a lot for these details, I really mean it.
> 
> > 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.
> 
> Ok.
> 
> > I'd call that a bug!
> > Can you tell us which blog you dragged onto the canvas, or does this
> > happen with all blocks?
> 
> It happens with any block, as simple as the logical AND block, or 
> Constant waveform source
> 
> I was tracing the call before I receive your reply, and for now, here is 
> what I found:
> 
>      BlockTreeWindow.py:
>      def _handle_drag_get_data(self, widget, drag_context, 
> selection_data, info, time):
>          key = self._get_selected_block_key()
>          if key:
>              # key is a valid text string, e.g. “blocks_and_xx” or 
> “analog_const_source_x”
>              selection_data.set_text(key, len(key))
> 
> 
>      DrawingArea.py:
>      def _handle_drag_data_received(self, widget, drag_context, x, y, 
> selection_data, info, time):
>          coords = x / self.zoom_factor, y / self.zoom_factor
>          # here, selection_data is empty (no data, no text, no type), I 
> can’t tell why.
>          self._flow_graph.add_new_block(selection_data.get_text(), 
> coords)
> 
> 
>      flowgraph.py:
>      def add_new_block(self, key, coor=None):
>          id = self._get_unique_id(key)
>          ...
>          # key is None, and exception is raised
>          block = self.new_block(key)
> 
> 
> > 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?
> 
> No, I’ve removed all the previous GNUradio installation, and Homebrew 
> always installs each app in its own versioned directory, here 
> “/usr/local/Cellar/gnuradio/3.8.0.0-rc2/“
> There is no custom PYTHONPATH, and I also unset GRC_BLOCKS_PATH from a 
> previous setup. When I edit the Python file (to track down this issue), 
> my trace messages are executed as expected.
> 
> PYTHONPATH is therefore defined to:
> PYTHONPATH="/usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/dist-packages:\
>              
> /usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/site-packages:\
>              
> /usr/local/Cellar/gnuradio/3.8.0.0-rc2/libexec/vendor/lib/python3.7/site-packages"
> 
> 1: lib/python3.7/dist-packages: gnuradio, pmt
> 2: lib/python3.7/site-packages: volk_modtool
> 3: libexec/vendor/lib/python3.7/site-packages# Python modules for 
> gnuradio (yaml, lxml, six, mako, click, …)
> 
> 
> Thanks for your help,
> Emmanuel.
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>