Re: [Discuss-gnuradio] [USRP-users] [RFNoC] Transition of branch from rfnoc-devel to master

[Rob Kossler]

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 <address@hidden> 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
address@hidden
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com