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.v...@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 >
