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

[Martin Braun]

On 07/12/2018 02:45 PM, Rob Kossler wrote:
> 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?

Hey Rob,

good question. First of all, we missed the time when we should have
changed the version on master branch to 3.13 and flag it as development
(which is now remedied). That would normally be your first indicator.

The other thing you can use is, when using master branch to do RFNoC
work, you have to specify -DENABLE_RFNOC=ON during CMake. When you do
that, you will have additional info available in your software project.
See how gr-ettus checks for the existence of RFNoC:

https://github.com/EttusResearch/gr-ettus/blob/cd6db6b2f6d181e117c0b100f112669e2774ce11/CMakeLists.txt#L138-L141

...you can do something similar, and use CMake to set defines in your
source code (assuming you're using CMake).

The other thing I was curious about this is the value of UHD_VERSION.
On master branch, it was (until today) 3120099 as you say (it will
change to      when you compile the lastest master branch now).

On UHD-3.12, you're right that UHD_VERSION is 3120099, but it should
read 3120000 on the current version (and will become 3120001 on the next
one). We'll need to remedy that, too.

Thanks for bringing all of this up!

Cheers,
Martin


> 
> Rob
> 
> 
> On Mon, Jul 9, 2018 at 1:48 PM Martin Braun via USRP-users
> <address@hidden <mailto: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 <mailto:address@hidden>
>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>