New source code repository!

Hi Everyone,

I’m pleased to announce that we have combined all the source
code repositories in to a new unified subversion system!

In addition we are running Trac, http://gnuradio.utah.edu/trac,
which provides a unified bug-tracker, wiki and subversion code
browser.

We’ve also restructured the entire build process in a way that removes
the need for things like ./checkout, ./for-all-dirs and ./buildit

Johnathan C. will be following up with details on the new build
system. We think you’ll like it. There are bound to be a few rough
spots at first, so please bear with us, and let us know what’s not
working :wink:

I’d like to thank the following people and organizations for making this
possible:

Matt E. for bugging me non-stop about Trac, and insisting that we
make GNU Radio easier to build.

Jay Lepreau and the folks at the University of Utah’s Flux Research
Group for providing expertise, the machine, net connection and
industrial strength archiving. For those of you unfamiliar with
Flux and the Emulab - Network Emulation Testbed, take a look at
http://www.emulab.net. Their main networking testbed has about 300
machines in a cluster. What’s particularly interesting from the GNU
Radio point of view, is that they currently have about 20 machines
scattered about with USRP’s attached. The USRP’s have RFX-900
daughterboards, and best of all, these machines can be used by you
to perform wireless networking experiments.

For information on Emulab, take a look their web site. If you’re
interested in running wireless experiments on the testbed, there’s
already a GNU Radio project registered. Talk to me and I can add
you to the project.

Finally, I want to thank Johnathan C. for kicking some serious
ass making this all happen. Johnathan has been handling the sys
admin on the new machine, and is to blame for the restructuring of
the build system :wink:

For those of you who just want to dive in: create a new directory
and cd into it, then execute these commands:

$ svn co http://gnuradio.utah.edu/svn/gnuradio/trunk gnuradio
$ cd gnuradio
$ ./bootstrap
$ ./configure
$ make && make check
$ sudo make install

Regarding trac, we’ve got the bug tracker initialized, please feel
free to create “tickets” (bug reports / enhancement requests).

We still need to port the old usemod wiki pages to trac. Any
volunteers? It’s pretty straight-forward, and I can provide details.
There is a “bulk load” command line tool to get them in. Also, we
still need to create a guest account on the wiki to let folks edit.
The plan is to use CAPTCHAs (visual Turing tests) and let anonymous
folks edit, but that code’s not in yet.

Committers, we’ll need to set you up to be able to write to svn. The
backend is using WebDAV with htdigest authentication. We’re lacking a
good GUI to do this now, so here’s how it’s going to work. Send me a
pgp/gpg encrypted message with your preferred user name and a decent
password. (My keys are here http://comsec.com/pgp-keys.txt)
When we run out of things to do, we’ll fix this problem, but for now,
we’ll go with this. If anybody can point us to code that already
handles this (in less than 2000 lines of code), please do.

Also, if you’re not familiar with subversion – particularly the best
practices for branching and merging, and the recommended format of
commit messages on merges – please take a look at the docs:
http://subversion.tigris.org.

The repo is laid out like this:

gnuradio/trunk/{gnuradio-core,gnuradio-examples,usrp,gr-usrp,…}
gnuradio/tags
gnuradio/branches
gnuradio/branches/developers/{eb,jcorgan,…}

gnuradio/trunk corresponds to CVS head. Please ensure that this code
always builds. If you’re working on a non-trivial change, it’s a good
idea to create a new branch using svn copy, do the work on the branch,
and then merge it into trunk when it’s stable.

If any of you have uncommitted code in a cvs checkout, please generate
a diff against cvs HEAD (or use the tag "SECOND_MIGRATION_2006_08_04)
and apply the diffs to svn.

That’s it for now. Look for Johnathan’s detailed note a bit later.

Best wishes,
Eric

Eric B. schrieb:

Also, we
still need to create a guest account on the wiki to let folks edit.
The plan is to use CAPTCHAs (visual Turing tests) and let anonymous
folks edit, but that code’s not in yet.

Are you using the trac SpamFilter plugin? Otherwise you will have the
Wiki spam problem^3 in the bug tracker.

Andreas S. wrote:

Are you using the trac SpamFilter plugin? Otherwise you will have the
Wiki spam problem^3 in the bug tracker.

We are not using that plug-in (yet), though we may.

I’ll be writing a longer email later today with more details of the new
system, but let me address this one issue here.

Short-term, in order to create or modify a wiki page or ticket, you need
to login in to the system with a guest account. The user name is
‘guest’, the password is ‘gnuradio’.

This is simply to prevent automated bots from spamming the wiki and trac
system.

In the future, we’re going to implement CAPTCHAs for these sort of
things. See http://en.wikipedia.org/wiki/Captcha for more information.
Right now Trac does not provide the hooks for this sort of thing so we
may have to custom code them.

-Johnathan

Johnathan C. schrieb:

Short-term, in order to create or modify a wiki page or ticket, you need
to login in to the system with a guest account. The user name is
‘guest’, the password is ‘gnuradio’.

That’s probably enough to keep the bots away. I have seen some very
badly spammed tracs, just wanted to make sure it doesn’t happen to
gnuradio.

Just a few words about the new build system and things yet to be done.

In addition to the switch from CVS to Subversion, GNU Radio is now
managed as a single hierarchy of files, separated into individual
component directories as before. However, the GNU Autotools-based build
scripts that existed in each directory before have been replaced by a
single top-level build:

http://gnuradio.org/trac/browser/gnuradio/trunk

The single exception to this is the gr-how-to-write-a-block component,
which has been left untouched, and is not built by the top-level build.
This directory still demonstrates how to build a GNU Radio component
“outside the tree,” and can remain as a template to base your own
projects from.

From the perspective of a user, you’ll need to note several changes.

First the entire repository is checked out; you no longer need to decide
which directories apply and individually grab those or delete them from
the ones gotten by the old gr-build setup:

svn co http://gnuradio.utah.edu/svn/gnuradio/trunk gnuradio
cd gnuradio

The first thing to do is to run the ./bootstrap script found in the root
of the source tree. This script runs the GNU Autotools and creates the
top-level ./configure script. Then run this script:

./configure

There are compile time dependencies both for the core libraries of GNU
Radio as well as the remaining components. The top-level configuration
script will abort if fundamental dependencies that all components depend
upon (such as SWIG or Python) are not found.

For the remainder, the top-level configuration will determine which
components can or cannot be built based on the what it finds. For
example, when running ./configure on a Linux machine, the
gr-audio-windows component will fail its dependency check and not be
marked for compilation. At the end of the ./configure process, a report
is issued indicating which packages will and won’t be built.

The standard ‘make’, ‘make check’, and ‘sudo make install’ commands work
as expected:

make && make check
sudo make install

At this point, you have a fully installed version of GNU Radio.

For GNU Radio developers:

No .cc, .py, .i or .h files were harmed in the production of this new
build system!

All of the source code changes needed to consolidate the build into a
top-level one were made in Makefile.am’s or other related autotools
files. A great deal of care was spent to ensure that all automated qa
tests passed; there are a few exceptions noted below.

The conversion to a single configure.ac was made by extracting the
component specific configuration directives into a separate m4 macro for
each component. These live down in the /config directory and start with
the grc_ prefix. The configure.ac script invokes these in the correct
order near the end after all the fundamental dependency checks are
satisfied.

One major change has been to have failed dependency checks mark a
variable instead aborting the configuration. The script maintains a
running list of successful components and uses that list to decide which
subdirectories to recurse into.

Since the top-level directory is now one higher than before, there have
been many changes in paths to add the component subdirectory name.
You’ll see this in Makefile.am and other places.

Finally, during the build, all references to include files, libraries,
and Python modules occur from within the build tree hierarchy. This is
because none of the prior components is installed into the filesystem.
Additionally, the qa tests require some path hackery to make sure the
loaded modules come from the build tree vs. the installed tree.

Here are some component specific notes, including some things that are
broken right now.

gr-audio-osx:
gr-audio-windows:

I don’t have access to either of these type of systems to test these
out. All the changes have been applied similar to what has been done to
other directories, but all that has been tested in the “failed
dependency” code path. Please test and report bugs in Trac, or even
better fix them and check in the code. :slight_smile:

gr-audio-portaudio:

The PKGCONFIG macro has been retained to check for the existence of
portaudio >= 19. As I only have rev. 18, I cannot test this.

gr-error-correcting-codes:

The qa tests in the Python directory have been disabled in the
Makefile.am. While configuration and compilation succeed, the
non-standard layout of the library directories breaks the script.

Overall:

The build system works but has not been optimized. Over the next few
days and weeks expect to see Eric and I refactoring some common things.
And of course, there will be bugs I’ll be fixing for a while yet…

I will write up more notes as a I think of them and post to the list.
Please feel free to report build system bugs in the Trac ticket system.

At this point, I shall recall the infinite wisdom of Sir Winston
Churchill:

“GNU Autotools is the worst cross-platform configuration management
system ever devised, except for all the rest.”

Or something like that :slight_smile:

And once again, thanks go to Jay Lepreau and his team at the University
of Utah’s Flux Research Group for their generous hosting and network
bandwidth.

-Johnathan C.

On Fri, Aug 04, 2006 at 05:07:42PM -0700, Johnathan C. wrote:

Just a few words about the new build system and things yet to be done.

In addition to the switch from CVS to Subversion, GNU Radio is now
managed as a single hierarchy of files, separated into individual
component directories as before. However, the GNU Autotools-based build
scripts that existed in each directory before have been replaced by a
single top-level build:

http://gnuradio.org/trac/browser/gnuradio/trunk

Make that http://gnuradio.utah.edu/trac/browser/gnuradio/trunk

Eric

On Sat, Aug 05, 2006 at 11:05:43AM +0930, Berndt Josef W. wrote:

`/home/wulf/projects/gnuradio/gnuradio/gnuradio-core/doc’
gmake: *** [all-recursive] Error 1

In gr-radar the build fails due to

time_series.cc:37
if ((d_fd = open(d_filename.c_str(), O_RDONLY | O_LARGEFILE, 0660)) == -1){

NetBSD’s open() function doesn’t support the O_LARGEFILE flag. I guess all
files are large… :slight_smile:

Thanks for the report and the fixes!

Eric


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

On Saturday 05 August 2006 12:44, Eric B. wrote:

Eric
It builds and installs fine, however there seems to be a problem with
the
audio support which doesn’t seem to pickup that we need to link agains
the
libossaudio library. I had to manually add -lossaudio in the Makefile of
gr-audio-oss/src/Makefile. Will have a look at this tonight.

BTW: all tests pass on make check in the top directory… :slight_smile:

Find below is the configuration for NetBSD


The following GNU Radio components have been successfully configured:

config
gnuradio-core
gnuradio-examples
usrp
gr-usrp
gr-audio-oss
gr-atsc
gr-error-correcting-codes
gr-gsm-fr-vocoder
gr-radar
gr-radio-astronomy
pmt
gr-video-sdl
gr-wxgui

However, the following components did not configure successfully due to
missing dependencies:

gr-audio-alsa
gr-audio-jack
gr-audio-osx
gr-audio-portaudio
gr-audio-windows
gr-comedi

cheerio Berndt

Berndt Josef W. wrote:

On Saturday 05 August 2006 12:44, Eric B. wrote:

It builds and installs fine, however there seems to be a problem with the
audio support which doesn’t seem to pickup that we need to link agains the
libossaudio library. I had to manually add -lossaudio in the Makefile of
gr-audio-oss/src/Makefile. Will have a look at this tonight.

I think I know how this might have happened; it was an oversight on my
part in gr-audio-oss/src/Makefile.am. If you you file a separate bug on
this for me I’ll take care of it.

-Johnathan

On Sat, Aug 05, 2006 at 11:05:43AM +0930, Berndt Josef W. wrote:

sim-airplane.cc:295
d_sample_rate(sample_rate), d_gain(exp10(gain_db/10))

sim-airplane2.cc:371
d_sample_rate(sample_rate), d_gain(exp10(gain_db/10))

NetBSD doesn’t support exp10() function

Berndt, I think I’ve fixed these (not the doxygen stuff) in trunk.

Can you please update and re-test? You’ll need

./bootstrap && ./configure

since there were some configure.ac changes.

Thanks!
Eric

Angilberto Muniz Sb wrote:

USRP should run by itself…)
Please shade some light…

The USRP is wired such that only the FX2 can control the AD9862s.

You can change this by adding R2001, R2004, and R2005 to the USRP. All
should be Zero-ohm resistors. Be careful, because you will now have
multiple drivers of these nets. You’ll need to have the FX2 STOP
driving them before you make the FPGA drive them.

This will allow the FPGA to control the AD9862s. You can also make the
FPGA control the tuning of the RFX-series daughterboards. Send me mail
if you need that.

Matt

Hi All,

Im working on a project that needs a continuos update
of a slow varying DC signal. I was able to realize
part of the project and put it into the FPGA. Now I
need a way to update the AUX_DAC port on the 9862, but
aparently that is handled by the USB uController ! Is
that correct ? To set up the AUX_DAC do DO have to
waste USB bandwidth? (My intent was to use the PC
just to download the FPGA image, do some setup and the
USRP should run by itself…)
Please shade some light…

Regrds,

Angilberto.


Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Good to know there is a solution…

Matt, when you say “You’ll need to have
the FX2 STOP driving them before you make the FPGA
drive them”, you mean I’ll have to break the wires
between FX2 and AD9862 or you mean I’ll have the
modify the FX2 firmware so to make the AD9862
controllable by both the FX2 and the FPGA?

Angilberto.

— Matt E. [email protected] wrote:

aparently that is handled by the USB uController !
The USRP is wired such that only the FX2 can control
This will allow the FPGA to control the AD9862s.
You can also make the
FPGA control the tuning of the RFX-series
daughterboards. Send me mail
if you need that.

Matt


Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs