> 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
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment