gnuradio-for-mac-without-macports
gnuradio-for-mac-without-macports copied to clipboard
ktemkin
Update to GNU Radio 3.8.1.0
GNU Radio has made release 3.8.1.0. This is a maintenance release with a very long list of bug fixes, usability improvements, and feature additions.
branch: maint-3.8 tag: v3.8.1.0 hash: 867b0ab9191ff6c6d5d8f49b5b95fdd884e92a07 url: https://github.com/gnuradio/gnuradio/releases/tag/v3.8.1.0
Relevant to issue https://github.com/ktemkin/gnuradio-for-mac-without-macports/issues/84 this release still has a VOLK submodule pointer. The non-imminent 3.9 release will not have it and the master branch removed it today. VOLK is now treated as a regular system library.
This project is awesome, thank you so much for making and maintaining this!
The build failed because the script prepends a 'v' before the specified GNURADIO_BRANCH. My recommendation is to remove the hidden 'v' so the branch actually pulled is easily visible at the top of the script. https://github.com/ktemkin/gnuradio-for-mac-without-macports/blob/master/build.sh#L2623
@dkozel good catch; I've removed the 'v' so hopefully this next build passes :)
@beaugunderson sorry to keep bouncing this back instead of openning a PR, I'm overloaded at the moment.
It looks like the script tries to checkout the GNURADIO_BRANCH as a commit rather than as a branch and then checking out the GNURADIO_HASH.
@dkozel no worries! my fault for assuming it would be easy :) I'll take a closer look at this, likely tonight
Awesome -- I took a look earlier, came to the same conclusion, and then got distracted. At a cursory inspection, it looked like the GNURADIO_BRANCH variable is misleadingly named; and actually is looking for a tag.
The correct tag would be v3.8.1.0.
https://github.com/gnuradio/gnuradio/releases/tag/v3.8.1.0
I do think the ability to build arbitrary hashes from whatever branch (in the main repo) would be a nice feature.
I think the original intent was to check out a tag and make sure it's the expected one -- but I think we can probably switch to just using a symbolic name (which would typically be a tag, but could also be a branch or hash).
That should probably be a separate issue -- in the interim, let me edit the relevant file and let it kick off a build.
Oof; looks like we might need to tweak some more URLs. Build failed trying to grab swig.
@ricky-bos There's a few hardcoded mentions of Python 3.7 in the build script. The GNU Radio core is compatible with Python 3.8. https://github.com/ktemkin/gnuradio-for-mac-without-macports/blob/560d51574f876f8a44829ba416737dfa965953b5/build.sh#L76
Can you open a separate issue for the feature request of support for different Python versions?
@ktemkin I just tried downloading the same SWIG tar as the build script and it succeeded. I don't know where the failure was, but it seems like temporary. The URL is correct.
might make sense to have retry functionality in the download function :)
Naively kicking off another build and hoping the URL issue was indeed temporary and resolves itself. If it doesn't, I'll actually put some thought into a solution. :)
Following up, this one failed with:
00:00:00 CMake Error at CMakeLists.txt:427 (message):
00:00:00 VOLK required but not found.
It seems like we'll need to implement the suggestion in #84 for this to build successfully?
@beaugunderson VOLK is still a git submodule in the 3.8 release series. As the script worked for 3.8.0.0 it should be the same for 3.8.1.0.
Would you be interested in hopping on a call sometime to talk over the build issues? I'd really like to get the 3.8.1.0 update out, it's significantly better.