Re: Trying to compile gr-osmosdr on windows

[Ryan Volz]

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