Re: Trying to compile gr-osmosdr on windows

[Mitja kocjančič]

Well, after trying your branch and looking to config output more closly it seams that it realy tries to regenerate python bindings: https://user-images.githubusercontent.com/6347325/165609413-45a0b65f-d193-4ed8-999c-c9328c11551a.png

for source.h and sink.h

now my source.h and sink.h line endings are CRLF (/r/n)

while the hash is proably calculated for linux line endings (LF (/n) so no wonder it differs

I guess git converts line endings from linux to windows, I guess I wasn't careful when installing it: https://troyready.com/blog/photos/tech/git-windows-dont-convert-line-endings/git-win-install-line-endings.jpg

and now it bites me because of that (I only thought old notepad would have problems with line endings and nothing else, I guess in this edge case, they also matter)

Now I have 2 options here

1. Convert line endings to LINUX ones on every file (I also need to tell github not to convert them in the future: git config --global core.autocrlf false ) (not sure if the rest of GNURadio stuff cares about line endings)

2. Modify hash function in GROsmoSDR to not include line endings in hash calculation (this would probably be a good thing to do for portability)

Now the question is now: Why cannot I regenerate python bindings? (it seams bind_oot_file.py has an argument --include which is empty but shouldn't be)

I tried sneaking some debug info: 

message(STATUS "COMMAND: bind_oot_file.py --output_dir " ${CMAKE_CURRENT_SOURCE_DIR}/.. " --prefix " ${CMAKE_INSTALL_PREFIX} " --module " ${name} " --filename " ${header_full_path} " --status " ${CMAKE_CURRENT_BINARY_DIR}/${file}.regen_status " --flag_automatic " ${flag_auto} " --flag_pygccxml " ${flag_pygccxml} " --defines " ${defines} " --include " ${extra_include_list})

inside  gnuradio/cmake/Modules/GrPybind.cmake but it seams this is eather called from somewhere else or the file doesn't listen to changes (I tried putting blablah inside and cmake didn't even complain so...)

Can anyone else regenerate python bindings? (it should be easy to make the hash different to try that, just put an empty #define nothing inside source.h and sink.h and see if bindings are secsesfully regenerated)

because it seams that bindings don't generate properly and nobody noticied that yet since I am not sure if source.h and sink.h change much, or it could also be that because I am building this on windows I am hitting some edges cases and have this interesting problems :)

V V sre., 27. apr. 2022 ob 20:36 je oseba Ryan Volz <ryan.volz@gmail.com> napisala:

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