Reorganization of gnuradio-examples in trunk r6279

All,

As of revision 6279 of the GNU Radio trunk software, the
gnuradio-examples hierarchy has undergone some reorganization.

First, a new top-level component has been created, ‘gr-utils’, to hold
many of the commonly used USRP scripts that aren’t really examples, but
rather utilities. These now get installed onto the system path so they
can be conveniently run from anywhere:

usrp_benchmark_usb.py: Test USB<–>USRP throughput performance
usrp_fft.py: Plot FFT, waterfall, or scope of USRP Rx
usrp_oscope.py: Plot scope of USRP Rx with extra options
usrp_print_db.py: Prints list of installed USRP daughterboards
usrp_rx_cfile.py: Record raw USRP Rx data to a file
usrp_rx_nogui.py: Receive common analog mods (AM, FM, WFM)
usrp_siggen.py: Generate USRP Tx signals
usrp_test_counting.py: Test USRP firmware/USB path integrity
usrp_test_loop.py: Test USRP digital loopback capability
usrp_test_loop_lfsr.py: Test USRP digital loopback (alternate)

This component is dependent on having gnuradio-core, gr-usrp, and
gr-wxgui also configured for build; this is the default.

The gnuradio-examples component itself now installs its various
sub-directories into $(prefix)/share/gnuradio/examples/…, so you don’t
need to keep the source tree lying around to view or run the examples.

This allows individual gnuradio-components to install examples into this
hierarchy. So the channel-coding examples have been moved into
gr-trellis, and only install if gr-trellis itself is being installed.
Likewise, the ATSC examples now install onto the system from gr-atsc.

Some of the cruft has been deleted or moved into ‘limbo’ in the
repository, and don’t get installed.

These changes hopefully improve the usability of the GNU Radio
distribution.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

On Tuesday 04 September 2007 12:39:00 Johnathan C. wrote:

usrp_benchmark_usb.py: Test USB<–>USRP throughput performance
This component is dependent on having gnuradio-core, gr-usrp, and

Some of the cruft has been deleted or moved into ‘limbo’ in the
repository, and don’t get installed.

These changes hopefully improve the usability of the GNU Radio
distribution.

Can we also add a switch that enables building individual modules
“outside”
the source tree the way it was prior to GNU-Radio 3.0.2?

This will allow building packages as individual modules. The pkgsrc
framework
keeps track of the dependencies and enables users to pick and choose
modules
for installation pulling in dependencies as required. The pkgsrc modules
are
currently patched to facilitate this behaviour. The pkgsrc sources and
the
corresponding patches can be found on:

http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/ham/

I’ve made mentioning of this many times before but sofare haven’t
received a
reponse nor seen any action. Just let me know if there is any hope to
see
this implemented.

cheerio Berndt

Berndt Josef W. wrote:

Can we also add a switch that enables building individual modules “outside”
the source tree the way it was prior to GNU-Radio 3.0.2?

The way it was prior to 3.0.2 (or maybe it was 3.0.3) was broken. The
‘make check’ process could fail because of linkage outside the tree vs.
inside during a build.

This will allow building packages as individual modules.

I understand the benefit this would have; we will at least reexamine it
after the 3.1 release, but no promises.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

On Wednesday 05 September 2007 04:03:23 Johnathan C. wrote:

Berndt Josef W. wrote:

Can we also add a switch that enables building individual modules
“outside” the source tree the way it was prior to GNU-Radio 3.0.2?

The way it was prior to 3.0.2 (or maybe it was 3.0.3) was broken. The
‘make check’ process could fail because of linkage outside the tree vs.
inside during a build.

That’s why I suggested a configure argument switch, which is disabled by
default. It would make life lot easier for package builder, well at
least for
those that do not want to build monolithic packages. Its easy to
implement
and has no impact on current methodology whatsoever, as it would require
a
conscious decision in getting this wrong!

This will allow building packages as individual modules.

I understand the benefit this would have; we will at least reexamine it
after the 3.1 release, but no promises.

You make my request sound like a complex issue similar to that of an API
change. It merely adds another configure option, which only requires a
couple
of minor changes in the configure script and Makefile.common file.

cheerio Berndt

On Wed, Sep 05, 2007 at 05:05:21AM +0930, Berndt Josef W. wrote:

That’s why I suggested a configure argument switch, which is disabled by
You make my request sound like a complex issue similar to that of an API
change. It merely adds another configure option, which only requires a couple
of minor changes in the configure script and Makefile.common file.

cheerio Berndt

Hi Berndt,

Right now Johnathan and I are dealing with getting 3.1 out the door.
We think that a good, solid solution to the problem is more
complicated than you do. We understand what you want to do, and we
want to keep the ability to test against non-installed code. Thus, a
solution requires the ability to do both.

If you think that we’ve missed the boat on the complexity, I’d
certainly welcome a patch (after 3.1 is out), that implements what you
want, as long as it still supports the existing behavior. Assuming you
come up with a patch that works well, I don’t see any reason that it
couldn’t go into 3.1.1.

Eric