Hi Martin, Regarding the API version "guarantee", I am wondering if there is any way to distinguish between versions. Presently, it seems that branches 3.12 and master both have UHD_VERSION set to 3120099. I had previously been using UHD_VERSION to select (via #if) code appropriate to a given UHD version. However, my function call to "get_device3()" compiles successfully on master, but not on 3.12 (because this function is not part of the 3.12 API). So, I keep having to change my source code whenever compiling for one or the other. Is there a way for me to avoid this?
Rob On Mon, Jul 9, 2018 at 1:48 PM Martin Braun via USRP-users < usrp-us...@lists.ettus.com> wrote: > Hi all, > > we have recently been working more on the RFNoC side of things, and > there's some updates I want to bring to you. > > The first step we did to a more stable version of RFNoC is merging all > of the work on rfnoc-devel back into master. This will make it a lot > easier to keep features in sync between RFNoC and regular/vanilla UHD. > Going forward, we will no longer push updates to the rfnoc-devel > branches, and at some point we will delete those branches in favour of > master (for now, we'll leave them up so people following the existing > instructions won't get an error, but they will be frozen as of now). > > For those of you who aren't actively developing on RFNoC, there is no > difference (with the exception of E310 users, but I'll send out another > email on that in a bit). > For people playing with RFNoC, keep the following things in mind: > > - Anytime you read something referencing the rfnoc-devel branch, simply > change that to master branch. > - The RFNoC APIs are still disabled by default, and require using the > -DENABLE_RFNOC=ON CMake switch to use them > - If you have patches on top of rfnoc-devel, you may want to rebase them > on top of master. They should cleanly apply, as of now, the diff between > the two branches is minimal. > > Why do we require the `-DENABLE_RFNOC=ON`? The reason is, the APIs are > not covered by our guarantee that we won't change them (in case you were > unaware, we have a strong guarantee that we won't change APIs unless we > also change the API version number, i.e., all 3.11.* releases have the > same API). Think of setting that switch as a waiver that says "I have > understood that I am using APIs that do not have a strong guarantee of > being unchanged". > > On the FPGA branch, there is no such CMake switch, and the same branch > will server RFNoC and non-RFNoC users alike. > > Thanks all! > > Martin > > _______________________________________________ > USRP-users mailing list > usrp-us...@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio