[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Trying to compile gr-osmosdr on windows
From: |
Ryan Volz |
Subject: |
Re: Trying to compile gr-osmosdr on windows |
Date: |
Wed, 27 Apr 2022 14:36:02 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
Hi Mitja,
On 4/26/22 7:45 PM, Mitja kocjančič wrote:
...
BTW: if I go with 0.2.3, tag of GROsmoSDR how should I go about applying
your patches (is there a tool that would take a patch and apply it
automaticly, because I don't want to patch this by hand because then it
would surely take another month or 2 for me to patch this manualy :)
I just put my local branch with the patches up on Github, so you can now
just use that:
https://github.com/ryanvolz/gr-osmosdr/tree/conda-forge
However, I doubt the difference is significant from what you are already
using. I just have to base everything on a tagged release per
conda-forge policy.
Now I guess I need to figure out why does GROsmoSDR invoke bind_oot_file.py
Ok, so I found where this is getting invoked from:
https://github.com/gnuradio/gnuradio/blob/89d8da35acaa090172ed34951919048f39ac4a3f/cmake/Modules/GrPybind.cmake#L216-L252
So it should only be calling bind_oot_file.py when the hash of the
binding header file (sink_python.h) that it calculates does not match
what is in the header file itself, you have pygccxml, and the flag is
set within the header for the python bindings to be automatically
generated. It probably warns you about this when you run cmake for
gr-osmosdr, but I'm guessing that was lost in the noise. There are a
couple possibilities:
1) The current hash on the master branch is wrong, and it needs to be
fixed. (And it is correct for v0.2.3+patches which I why I haven't see it.)
2) Your git checkout of gr-osmosdr has resulted in the use of different
line endings than what was used to generate the md5 hash, so your hash
doesn't match. This is specifically a Windows problem with line endings
being different than other platforms. This was fixed for main GNU Radio
(https://github.com/gnuradio/gnuradio/pull/4140), but maybe not for OOT
modules like gr-osmosdr in which case what happens depends on your local
settings.
Hope that helps!
Ryan