#
-# Copyright 2001,2002,2003,2004,2005 Free Software Foundation, Inc.
+# Copyright 2001,2002,2003,2004,2005,2006 Free Software Foundation, Inc.
#
# This file is part of GNU Radio
#
# Boston, MA 02111-1307, USA.
#
--------------------------------------------------------------------------------
+Welcome to GNU Radio!
+
+
+As of August 3, 2006 we have restructured the GNU Radio build process
+and moved the source code repository from CVS to subversion.
+
+Please see http://gnuradio.utah.edu/trac for the wiki, bug tracking,
+and source code viewer.
+
+The bleeding edge code can be found in our subversion repository at
+http://gnuradio.utah.edu/svn. To checkout the latest, use this
+command:
+
+ $ svn co http://gnuradio.utah.edu/svn/gnuradio/trunk co gnuradio
+
+For information about subversion, please see:
+ http://subversion.tigris.org/
- IMPORTANT
--------------------------------------------------------------------------------
-GNU Radio is now broken up into several packages. You're looking at
-the gnuradio-core. You'll probably want some or all of these too.
-Build and install them in the order listed here:
+GNU Radio is now distributed as one giant blob, instead of N smaller
+blobs. We believe that this will reduce some of the build problems
+people were seeing. Now you'll always get all of the code, and the
+configure step will determine which components can be built on your
+system.
- gnuradio-core # main library
- gnuradio-examples # examples
- gr-audio-alsa # support for sounds cards using ALSA (prefered under GNU/Linux)
- gr-audio-oss # support for sounds cards using OSS
- gr-audio-jack # support for JACK Audio Connection Kit
- gr-audio-windows # support for sounds cards using Windows Wave
- gr-comedi # support for DAQ cards using COMEDI
- gr-wxgui # GUI framework built on wxPython
- usrp # non-GNU Radio specific portion of usrp
- gr-usrp # glues usrp into GNU Radio
- mc4020 # GNU/Linux driver for Measurement Computing PCI-DAS4020/12 A/D board
- gr-mc4020 # the glue that ties the mc4020 driver into GNU Radio
+
+How to Build GNU Radio:
+
+ (1) Ensure that you've satisfied the external dependencies listed
+ below. With the exception of SDCC, the following GNU/Linux
+ distributions are known to come with all required dependencies
+ pre-packaged: Ubuntu 6.06, SuSE 10.0 (the pay version, not the
+ free download), Fedora Core 5. Other distribution may work too.
+ We know these three are easy. The required packages may be
+ contained on your installation CD/DVD, or may be loaded over the
+ net. The specifics vary depending on your GNU/Linux
+ distribution. See the wiki at
+ http://gnuradio.utah.edu/trac/wiki for details.
+
+ FIXME: update the wiki; talk about OS/X, NetBSD and MinGW too.
+
+ (2) do the "usual dance"
+
+ $ ./bootstrap # not reqd when building from the tarball
+ $ ./configure
+ $ make && make check
+ $ sudo make install
+
+
+That's it!
-------------------------------------------------------------------------------
KNOWN INCOMPATIBILITIES
- GNU Radio triggers bugs in g++ 3.3 for X86. DO NOT USE GCC 3.3.
- gcc 3.2 and 3.4 are known to work well.
+ GNU Radio triggers bugs in g++ 3.3 for X86. DO NOT USE GCC 3.3 on
+ the X86 platform. g++ 3.2, 3.4, and the 4.* series are known to work well.
-------------------------------------------------------------------------------
-Prerequisites (you may already have these):
+-------------------------------------------------------------------------------
+
+ External dependencies
+
+-------------------------------------------------------------------------------
+
+Prerequisites: Before trying to build these from source, please try
+your installation tool (apt-get, YaST, yum, urpmi, etc.) first.
+Contemporary distributions have these packages available.
+
+You'll need to do a bit of sleuthing to figure out what your OS and
+packaging system calls these. If your system has both a foo and a
+foo-devel package, install them both.
+
+
+(1) The "autotools"
+
+ autoconf 2.57 or later
+ automake 1.7.4 or later
+ libtool 1.5 or later
+
+If your system has automake-1.4, there's a good chance it also has
+automake-1.7 or later. Check your install disk and/or try:
+
+ $ man update-alternatives
+
+for info on how some distributions support multiple versions.
+
-(1) pkgconfig 0.15.0 or later http://www.freedesktop.org/Software/pkgconfig
+(2) pkgconfig 0.15.0 or later http://www.freedesktop.org/Software/pkgconfig
From the web site:
scripts you may have seen with a single tool.
-(2) FFTW 3.0 or later http://www.fftw.org
+(3) FFTW 3.0 or later http://www.fftw.org
IMPORTANT!!! When building FFTW, you MUST use the --enable-single and
--enable-shared configure options. This builds the single precision
respectively.
-(3) Python 2.3 or later http://www.python.org
+(4) Python 2.3 or later http://www.python.org
Python 2.3 or later is now required. If your distribution splits
python into a bunch of separate RPMS including python-devel or
libpython you'll most likely need those too.
-(4) Numeric python library http://numeric.scipy.org
+(5) Numeric python library http://numeric.scipy.org
Provides a high performance array type for Python.
+http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=1351
-(5) The Boost C++ Libraries http://www.boost.org
+(6) The Boost C++ Libraries http://www.boost.org
-We use the Smart Pointer library. Fedore Core 2 has a package for
-this, boost-devel-1.31.0-7. Otherwise download the source and follow
-the build instructions. They're a bit different from the normal
-./configure && make
+We use the Smart Pointer library. Your distribution almost certainly
+has the boost libraries available. In the unlikely event that it
+doesn't, download the source and follow the build instructions.
+They're different from the normal ./configure && make
-(6) cppunit 1.9.14 or later. http://cppunit.sourceforge.net
+(7) cppunit 1.9.14 or later. http://cppunit.sourceforge.net
Unit testing framework for C++.
-(7) Simple Wrapper Interface Generator. http://www.swig.org
+(8) Simple Wrapper Interface Generator. http://www.swig.org
These versions are known to work:
1.3.23, 1.3.24, 1.3.25, 1.3.27, 1.3.28, 1.3.29
-----------------------------------------------------------------
-For the impatient, just do the following:
+(9) SDCC: Small Device C Compiler. http://sdcc.sourceforge.net/
+
+Use version 2.4.0 or later.
+
+This includes a C compiler and linker for the 8051. It's required to
+build the firmware for the USRP. If you don't have a USRP, don't
+worry about it.
+
- $ ./configure
- $ make
- $ make check
- $ make install
+Optional, but nice to have:
-If it doesn't work, fix it and send us a patch...
+(10) wxPython. Python binding for the wxWidgets GUI framework.
+Use version 2.5.2.7 or later. Again, your distribution almost
+certainly has this available.
+As a last resort, build it from source (not recommended!)
+http://www.wxpython.org
-See http://www.gnu.org/software/gnuradio/ for an overview.
-The project is hosted at http://savannah.gnu.org/projects/gnuradio/
+----------------------------------------------------------------
If you've got doxygen installed and provide the --enable-doxygen
configure option, the build process creates documentation for the
class hierarchy etc. Point your browser at
-gnuradio-core/doc/html/index.html
+gnuradio/gnuradio-core/doc/html/index.html
To run the examples you'll need to set PYTHONPATH.
You may want to add this to your ~/.bash_profile
-
-----------------------------------------------------------------
-
- Notes on building GNU Radio from the CVS repository
-
-----------------------------------------------------------------
-
-If you're building from the CVS repository YOU MUST BE PLAYING BY THE
-RULES THAT THE OTHER DEVELOPERS ARE USING. This is especially true
-with regard to the versions of the tools below...
-
-Ensure that you've got THESE VERSIONS of the following tools:
-
- autoconf 2.57 or later
- automake 1.7.4 or later
- libtool 1.5 or later
- swig 1.3.{23,24,25,27,28,29}
-
-If you're using earlier versions than these, don't expect the system
-to build. Get these versions or something later. They're available
-at any of the GNU mirrors.
-
-Then, check out a copy of GNU Radio.
-
-See http://www.gnu.org/software/gnuradio for directions on anonymous
-access to the CVS repository.
-
-Then in the top level directory, execute
-
- $ ./bootstrap
-
-This builds configure from configure.ac and also builds all the
-Makefile.in's from the Makefile.am's.
-
-Then carry on as usual:
-
- $ ./configure
- $ make
- $ make check
- $ make install
-
-
-For the easiest way to build from CVS, see
-http://comsec.com/wiki?HowtoBuildFromCVS
-
-
-
Another handy trick if for example your fftw includes and libs are
installed in, say ~/local/include and ~/local/lib, instead of
/usr/local is this:
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/local/lib
$ make CPPFLAGS="-I$HOME/local/include"
-
--- /dev/null
+Building and using gnuradio on windows (win32) using mingw
+
+Required tools and libraries
+
+MingW and Msys
+Download the latest stable version from the mingw site oand follow their installation instructions)
+
+Python for windows version 2.4 (or higher)
+You do not need to build this yourself.
+You can just install the windows executable which you can find on the python site.
+I am not sure if it will work if you have speces in your python pathname.
+I recommend installing it in C:\Python24 or D:\Python24
+
+Libtool
+If you are building from cvs you need a recent libtool
+msys comes with libtool, but the version distributed with current mingw doesn't work with gnuradio.
+download, build and install a recent libtool
+
+cppunit
+Build and install cppunit
+
+boost
+build and install boost (maybe you can get away with only unpacking the source, we only use the boost header files)
+If you build boost, you first have to download jam (boost jam) for win32. (Do not use build and use the cygwin version)
+
+build environment:
+You need to have the following files on your PATH:
+python.exe python24.dll libcppunit-1-10-2.dll libfftw3f-3.dll fftwf-wisdom.exe cppunit-config
+If you have cygwin installed Make sure that NO cygwin executables are on your path.
+
+needed on PATH:
+/usr/local/bin
+/mingw/bin
+/bin
+/c/Python24/ python.exe
+/c/Python24/libs python24.dll
+/c/Python24/DLLs
+/usr/local/bin or /mingw/bin or /my/special/installed/lib/folder/bin
+ libcppunit-1-10-2.dll
+ libfftw3f-3.dll
+ fftw-wisdom-to-conf
+ fftwf-wisdom.exe
+ cppunit-config
+/c/WINNT/system32
+/c/WINNT
+
+
+I made a little script set_clean_path.sh to set my path for building gnuradio where I just discard the original PATH (to get rid of the cygwin executables on my default path) and just include what is needed:
+
+#!/bin/sh
+export PATH=".:/usr/local/bin:/mingw/bin:/bin:/c/Python24:/c/Python24/DLLs:/c/Python24/libs:/my/special/installed/lib/folder/bin:/c/WINNT/system32:/c/WINNT:/c/WINNT/System32/Wbem:.
+
+You need to source this script to set the PATH.
+. ./set_clean_path.sh
+(notice the extra dot and space in the beginning of the line, this means source this file. Sourcing means execute it and remember all environment variables set in this script)
+
+If you are building from cvs it is recommended that you edit bootstrap to your needs and use it
+If you built a recent libtool and didn't overwrite the original libtool
+(because you installed the new version in /usr/local) then you have to tell aclocal to use the more recent libtool m4 macros.
+You can do this by appending -I /usr/local/share/aclocal to the aclocal commandline
+I also changed the aclocal and automake invocations to use the most recent version in my bootstrap script
+Here follows the bootstrap script I use
+
+#!/bin/sh
+rm -fr config.cache autom4te*.cache
+
+aclocal-1.8 -I config -I /usr/local/share/aclocal
+autoconf
+autoheader
+libtoolize --automake
+automake-1.8 --add-missing
+
+If you run this script it will convert a clean cvs checkout to a version which you can configure, build and install
+
+So now you can configure gnuradio.
+On win32 /mingw you need to give it a few parameters
+You need to tell it where cppunit is installed
+where boost include files are to be found
+where the pkg-config of libfftw is to be found
+to use a generic cpu (no 3Dnow,SSE,MMX) (This option will not be needed anymore soon)
+If you have boost installed in C:\boost_1_32_0 and cppunit and fftw in /usr/local then you would need the following configur commandline
+$ ./configure --with-md-cpu=generic --with-cppunit-prefix=/usr/local --with-boost-include-dir=/c/boost_1_32_0/include/boost-1_32 PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
+
+If everything went well you cannow do
+make
+make install
+
+Now you have a working gnuradio-core
+Now you can go on building and installing gr-audio-windows and windows usrp and wxgui
+remember that all gnuradio and python dlls need to be on your path to use gnuradio
+The gnuradio dlls are installed at
+/c/Python24/Lib/site-packages:/c/Python24/Lib/site-packages/gnuradio:/c/Python24/Lib/site-packages/gnuradio/gr
--- /dev/null
+# -*- Outline -*-
+#
+# Copyright 2004 Free Software Foundation, Inc.
+#
+# This file is part of GNU Radio
+#
+# GNU Radio is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# GNU Radio is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Radio; see the file COPYING. If not, write to
+# the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+# Boston, MA 02111-1307, USA.
+#
+
+
+Random notes on coding conventions, some explanations about why things
+aren't done differently, etc, etc,
+
+
+* C++ and Python
+
+GNU Radio is now a hybrid system. Some parts of the system are built
+in C++ and some of it in Python. In general, prefer Python to C++.
+Signal processing primitives are still built in C++ for performance.
+
+It is no longer possible to build user applications entirely in C++.
+Essential parts of the runtime system have been moved into Python.
+
+
+* C++ namespaces
+
+In the cleanup process, I considered putting everything in the
+gnuradio namespace and dropping the Gr|gr prefix. In fact, I think
+it's probably the right idea, but when I tested it out, I ran into
+problems with SWIG's handling of namespaces. Bottom line, SWIG
+(1.3.21) got confused and generated bad code when I started playing
+around with namespaces in a not particularly convoluted way. I saw
+problems using the boost::shared_ptr template in combination with
+classes defined in the gnuradio namespace. It wasn't pretty...
+
+
+* Naming conventions
+
+Death to CamelCaseNames! We've returned to a kinder, gentler era.
+We're now using the "STL style" naming convention with a couple of
+modifications since we're not using namespaces.
+
+With the exception of macros and other constant values, all
+identifiers shall be lower case with words_separated_like_this.
+
+Macros and constant values (e.g., enumerated values,
+static const int FOO = 23) shall be in UPPER_CASE.
+
+
+** Global names
+
+All globally visible names (types, functions, variables, consts, etc)
+shall begin with a "package prefix", followed by an '_'. The bulk of
+the code in GNU Radio logically belongs to the "gr" package, hence
+names look like gr_open_file (...).
+
+Large coherent bodies of code may use other package prefixes, but
+let's try to keep them to a well thought out list. See the list
+below.
+
+*** Package prefixes
+
+These are the current package prefixes:
+
+ gr_ Almost everything
+
+ gri_ Implementation primitives. Sometimes we
+ have both a gr_<foo> and a gri_<foo>. In that case,
+ gr_<foo> would be derived from gr_block and gri_<foo>
+ would be the low level guts of the function.
+
+ atsc_ Code related to the Advanced Television
+ Standards Committee HDTV implementation
+
+ usrp_ Universal Software Radio Peripheral
+
+ qa_ Quality Assurance. Test code.
+
+
+** Class data members (instance variables)
+
+All class data members shall begin with d_<foo>.
+
+The big win is when you're staring at a block of code it's obvious
+which of the things being assigned to persist outside of the block.
+This also keeps you from having to be creative with parameter names
+for methods and constructors. You just use the same name as the
+instance variable, without the d_.
+
+class gr_wonderfulness {
+ std::string d_name;
+ double d_wonderfulness_factor;
+
+public:
+ gr_wonderfulness (std::string name, double wonderfulness_factor)
+ : d_name (name), d_wonderfulness_factor (wonderfulness_factor)
+ {
+ ...
+ }
+ ...
+};
+
+
+** Class static data members (class variables)
+
+All class static data members shall begin with s_<foo>.
+
+
+** File names
+
+Each significant class shall be contained in it's own file. The
+declaration of class gr_foo shall be in gr_foo.h, the definition in
+gr_foo.cc.
+
+
+
+* Storage management
+
+Strongly consider using the boost smart pointer templates, scoped_ptr
+and shared_ptr. scoped_ptr should be used for locals that contain
+pointers to objects that we need to delete when we exit the current
+scope. shared_ptr implements transparent reference counting and is a
+major win. You never have to worry about calling delete. The right
+thing happens.
+
+See http://www.boost.org/libs/smart_ptr/smart_ptr.htm
+
+
+* Unit tests
+
+Build unit tests for everything non-trivial and run them after every
+change. Check out Extreme Programming:
+http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
+
+Unit tests should also be written for all examples. This should kill
+off the bit rot we've been plagued with.
+
+** C++ unit tests
+
+For C++ we're using the cppunit framework. cppunit has its bad
+smells, but it's mostly workable. http://cppunit.sf.net
+
+Currently each directory <dirname> contains files qa_<dirname>.{h,cc}
+that bring together all the qa_<foo> test suites in the directory.
+We ought to be able to automate this without too much trouble.
+
+The directory gnuradio-core/src/tests contains programs that run
+the tests. test_all runs all of the registered C++ unit tests.
+
+As far as I can tell, the cppunit TestFactoryRegistry maybe able to be
+tricked into doing what we want. As is, I don't think it's enough by
+itself, since there's nothing dragging the qa* files out of the
+library and into the program. I haven't tested out this idea.
+
+** Python unit tests
+
+We use the standard unittest package for unit testing of Python code.
+
+
+* Misc tips
+
+ccache, a compiler cache, can really speed up your builds.
+See http://ccache.samba.org/
+
+Be sure to create links for gcc and g++
+++ /dev/null
-GNU Radio -- History of visible changes.
-
-Copyright (C) 2001, Free Software Foundation, Inc.
-See the end for copying conditions.
-
-Please send GNU Radio bug reports to bug-gnuradio@fsf.org
-
-Version 0.2
-
-* This the first "real release"
-
-
-Version 0.1
-
-* We're working toward the first alpha distribution
-
-* The build strategy is in the processes of being converted to use
- automake. It is mostly complete, but there are still some untested directories
- which still contain Makefile.in's
-
--------------------------------------------------------
-Copying information:
-
-Copyright (C) 2001, Free Software Foundation, Inc.
-
- Permission is granted to anyone to make or distribute verbatim copies
- of this document as received, in any medium, provided that the
- copyright notice and this permission notice are preserved,
- thus giving the recipient permission to redistribute in turn.
-
- Permission is granted to distribute modified versions
- of this document, or of portions of it,
- under the above conditions, provided also that they
- carry prominent notices stating who last changed them.
-
+++ /dev/null
-#
-# Copyright 2001,2002,2003,2004,2005 Free Software Foundation, Inc.
-#
-# This file is part of GNU Radio
-#
-# GNU Radio is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2, or (at your option)
-# any later version.
-#
-# GNU Radio is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with GNU Radio; see the file COPYING. If not, write to
-# the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
-# Boston, MA 02111-1307, USA.
-#
-
--------------------------------------------------------------------------------
-
- IMPORTANT
-
--------------------------------------------------------------------------------
-
-GNU Radio is now broken up into several packages. You're looking at
-the gnuradio-core. You'll probably want some or all of these too.
-Build and install them in the order listed here:
-
- gnuradio-core # main library
- gnuradio-examples # examples
- gr-audio-alsa # support for sounds cards using ALSA (prefered under GNU/Linux)
- gr-audio-oss # support for sounds cards using OSS
- gr-audio-jack # support for JACK Audio Connection Kit
- gr-audio-windows # support for sounds cards using Windows Wave
- gr-comedi # support for DAQ cards using COMEDI
- gr-wxgui # GUI framework built on wxPython
- usrp # non-GNU Radio specific portion of usrp
- gr-usrp # glues usrp into GNU Radio
- mc4020 # GNU/Linux driver for Measurement Computing PCI-DAS4020/12 A/D board
- gr-mc4020 # the glue that ties the mc4020 driver into GNU Radio
-
-
--------------------------------------------------------------------------------
-
- KNOWN INCOMPATIBILITIES
-
-
- GNU Radio triggers bugs in g++ 3.3 for X86. DO NOT USE GCC 3.3.
- gcc 3.2 and 3.4 are known to work well.
-
--------------------------------------------------------------------------------
-
-Prerequisites (you may already have these):
-
-(1) pkgconfig 0.15.0 or later http://www.freedesktop.org/Software/pkgconfig
-
-From the web site:
-
-pkgconfig is a system for managing library compile/link flags that
-works with automake and autoconf. It replaces the ubiquitous *-config
-scripts you may have seen with a single tool.
-
-
-(2) FFTW 3.0 or later http://www.fftw.org
-
-IMPORTANT!!! When building FFTW, you MUST use the --enable-single and
---enable-shared configure options. This builds the single precision
-floating point version which we use. You should also use either the
---enable-3dnow or --enable-sse options if you're on an Athlon or Pentium
-respectively.
-
-
-(3) Python 2.3 or later http://www.python.org
-
-Python 2.3 or later is now required. If your distribution splits
-python into a bunch of separate RPMS including python-devel or
-libpython you'll most likely need those too.
-
-
-(4) Numeric python library http://numeric.scipy.org
-
-Provides a high performance array type for Python.
-
-
-(5) The Boost C++ Libraries http://www.boost.org
-
-We use the Smart Pointer library. Fedore Core 2 has a package for
-this, boost-devel-1.31.0-7. Otherwise download the source and follow
-the build instructions. They're a bit different from the normal
-./configure && make
-
-
-(6) cppunit 1.9.14 or later. http://cppunit.sourceforge.net
-
-Unit testing framework for C++.
-
-
-(7) Simple Wrapper Interface Generator. http://www.swig.org
-
-These versions are known to work:
- 1.3.23, 1.3.24, 1.3.25, 1.3.27, 1.3.28, 1.3.29
-
-----------------------------------------------------------------
-
-For the impatient, just do the following:
-
- $ ./configure
- $ make
- $ make check
- $ make install
-
-If it doesn't work, fix it and send us a patch...
-
-
-See http://www.gnu.org/software/gnuradio/ for an overview.
-The project is hosted at http://savannah.gnu.org/projects/gnuradio/
-
-
-If you've got doxygen installed and provide the --enable-doxygen
-configure option, the build process creates documentation for the
-class hierarchy etc. Point your browser at
-gnuradio-core/doc/html/index.html
-
-
-To run the examples you'll need to set PYTHONPATH.
-Note that the python version number in the path needs to match your
-installed version of python.
-
- $ export PYTHONPATH=/usr/local/lib/python2.3/site-packages
-
-You may want to add this to your ~/.bash_profile
-
-
-
-----------------------------------------------------------------
-
- Notes on building GNU Radio from the CVS repository
-
-----------------------------------------------------------------
-
-If you're building from the CVS repository YOU MUST BE PLAYING BY THE
-RULES THAT THE OTHER DEVELOPERS ARE USING. This is especially true
-with regard to the versions of the tools below...
-
-Ensure that you've got THESE VERSIONS of the following tools:
-
- autoconf 2.57 or later
- automake 1.7.4 or later
- libtool 1.5 or later
- swig 1.3.{23,24,25,27,28,29}
-
-If you're using earlier versions than these, don't expect the system
-to build. Get these versions or something later. They're available
-at any of the GNU mirrors.
-
-Then, check out a copy of GNU Radio.
-
-See http://www.gnu.org/software/gnuradio for directions on anonymous
-access to the CVS repository.
-
-Then in the top level directory, execute
-
- $ ./bootstrap
-
-This builds configure from configure.ac and also builds all the
-Makefile.in's from the Makefile.am's.
-
-Then carry on as usual:
-
- $ ./configure
- $ make
- $ make check
- $ make install
-
-
-For the easiest way to build from CVS, see
-http://comsec.com/wiki?HowtoBuildFromCVS
-
-
-
-Another handy trick if for example your fftw includes and libs are
-installed in, say ~/local/include and ~/local/lib, instead of
-/usr/local is this:
-
- $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/local/lib
- $ make CPPFLAGS="-I$HOME/local/include"
-
+++ /dev/null
-Building and using gnuradio on windows (win32) using mingw
-
-Required tools and libraries
-
-MingW and Msys
-Download the latest stable version from the mingw site oand follow their installation instructions)
-
-Python for windows version 2.4 (or higher)
-You do not need to build this yourself.
-You can just install the windows executable which you can find on the python site.
-I am not sure if it will work if you have speces in your python pathname.
-I recommend installing it in C:\Python24 or D:\Python24
-
-Libtool
-If you are building from cvs you need a recent libtool
-msys comes with libtool, but the version distributed with current mingw doesn't work with gnuradio.
-download, build and install a recent libtool
-
-cppunit
-Build and install cppunit
-
-boost
-build and install boost (maybe you can get away with only unpacking the source, we only use the boost header files)
-If you build boost, you first have to download jam (boost jam) for win32. (Do not use build and use the cygwin version)
-
-build environment:
-You need to have the following files on your PATH:
-python.exe python24.dll libcppunit-1-10-2.dll libfftw3f-3.dll fftwf-wisdom.exe cppunit-config
-If you have cygwin installed Make sure that NO cygwin executables are on your path.
-
-needed on PATH:
-/usr/local/bin
-/mingw/bin
-/bin
-/c/Python24/ python.exe
-/c/Python24/libs python24.dll
-/c/Python24/DLLs
-/usr/local/bin or /mingw/bin or /my/special/installed/lib/folder/bin
- libcppunit-1-10-2.dll
- libfftw3f-3.dll
- fftw-wisdom-to-conf
- fftwf-wisdom.exe
- cppunit-config
-/c/WINNT/system32
-/c/WINNT
-
-
-I made a little script set_clean_path.sh to set my path for building gnuradio where I just discard the original PATH (to get rid of the cygwin executables on my default path) and just include what is needed:
-
-#!/bin/sh
-export PATH=".:/usr/local/bin:/mingw/bin:/bin:/c/Python24:/c/Python24/DLLs:/c/Python24/libs:/my/special/installed/lib/folder/bin:/c/WINNT/system32:/c/WINNT:/c/WINNT/System32/Wbem:.
-
-You need to source this script to set the PATH.
-. ./set_clean_path.sh
-(notice the extra dot and space in the beginning of the line, this means source this file. Sourcing means execute it and remember all environment variables set in this script)
-
-If you are building from cvs it is recommended that you edit bootstrap to your needs and use it
-If you built a recent libtool and didn't overwrite the original libtool
-(because you installed the new version in /usr/local) then you have to tell aclocal to use the more recent libtool m4 macros.
-You can do this by appending -I /usr/local/share/aclocal to the aclocal commandline
-I also changed the aclocal and automake invocations to use the most recent version in my bootstrap script
-Here follows the bootstrap script I use
-
-#!/bin/sh
-rm -fr config.cache autom4te*.cache
-
-aclocal-1.8 -I config -I /usr/local/share/aclocal
-autoconf
-autoheader
-libtoolize --automake
-automake-1.8 --add-missing
-
-If you run this script it will convert a clean cvs checkout to a version which you can configure, build and install
-
-So now you can configure gnuradio.
-On win32 /mingw you need to give it a few parameters
-You need to tell it where cppunit is installed
-where boost include files are to be found
-where the pkg-config of libfftw is to be found
-to use a generic cpu (no 3Dnow,SSE,MMX) (This option will not be needed anymore soon)
-If you have boost installed in C:\boost_1_32_0 and cppunit and fftw in /usr/local then you would need the following configur commandline
-$ ./configure --with-md-cpu=generic --with-cppunit-prefix=/usr/local --with-boost-include-dir=/c/boost_1_32_0/include/boost-1_32 PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
-
-If everything went well you cannow do
-make
-make install
-
-Now you have a working gnuradio-core
-Now you can go on building and installing gr-audio-windows and windows usrp and wxgui
-remember that all gnuradio and python dlls need to be on your path to use gnuradio
-The gnuradio dlls are installed at
-/c/Python24/Lib/site-packages:/c/Python24/Lib/site-packages/gnuradio:/c/Python24/Lib/site-packages/gnuradio/gr
+++ /dev/null
-# -*- Outline -*-
-#
-# Copyright 2004 Free Software Foundation, Inc.
-#
-# This file is part of GNU Radio
-#
-# GNU Radio is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2, or (at your option)
-# any later version.
-#
-# GNU Radio is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with GNU Radio; see the file COPYING. If not, write to
-# the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
-# Boston, MA 02111-1307, USA.
-#
-
-
-Random notes on coding conventions, some explanations about why things
-aren't done differently, etc, etc,
-
-
-* C++ and Python
-
-GNU Radio is now a hybrid system. Some parts of the system are built
-in C++ and some of it in Python. In general, prefer Python to C++.
-Signal processing primitives are still built in C++ for performance.
-
-It is no longer possible to build user applications entirely in C++.
-Essential parts of the runtime system have been moved into Python.
-
-
-* C++ namespaces
-
-In the cleanup process, I considered putting everything in the
-gnuradio namespace and dropping the Gr|gr prefix. In fact, I think
-it's probably the right idea, but when I tested it out, I ran into
-problems with SWIG's handling of namespaces. Bottom line, SWIG
-(1.3.21) got confused and generated bad code when I started playing
-around with namespaces in a not particularly convoluted way. I saw
-problems using the boost::shared_ptr template in combination with
-classes defined in the gnuradio namespace. It wasn't pretty...
-
-
-* Naming conventions
-
-Death to CamelCaseNames! We've returned to a kinder, gentler era.
-We're now using the "STL style" naming convention with a couple of
-modifications since we're not using namespaces.
-
-With the exception of macros and other constant values, all
-identifiers shall be lower case with words_separated_like_this.
-
-Macros and constant values (e.g., enumerated values,
-static const int FOO = 23) shall be in UPPER_CASE.
-
-
-** Global names
-
-All globally visible names (types, functions, variables, consts, etc)
-shall begin with a "package prefix", followed by an '_'. The bulk of
-the code in GNU Radio logically belongs to the "gr" package, hence
-names look like gr_open_file (...).
-
-Large coherent bodies of code may use other package prefixes, but
-let's try to keep them to a well thought out list. See the list
-below.
-
-*** Package prefixes
-
-These are the current package prefixes:
-
- gr_ Almost everything
-
- gri_ Implementation primitives. Sometimes we
- have both a gr_<foo> and a gri_<foo>. In that case,
- gr_<foo> would be derived from gr_block and gri_<foo>
- would be the low level guts of the function.
-
- atsc_ Code related to the Advanced Television
- Standards Committee HDTV implementation
-
- usrp_ Universal Software Radio Peripheral
-
- qa_ Quality Assurance. Test code.
-
-
-** Class data members (instance variables)
-
-All class data members shall begin with d_<foo>.
-
-The big win is when you're staring at a block of code it's obvious
-which of the things being assigned to persist outside of the block.
-This also keeps you from having to be creative with parameter names
-for methods and constructors. You just use the same name as the
-instance variable, without the d_.
-
-class gr_wonderfulness {
- std::string d_name;
- double d_wonderfulness_factor;
-
-public:
- gr_wonderfulness (std::string name, double wonderfulness_factor)
- : d_name (name), d_wonderfulness_factor (wonderfulness_factor)
- {
- ...
- }
- ...
-};
-
-
-** Class static data members (class variables)
-
-All class static data members shall begin with s_<foo>.
-
-
-** File names
-
-Each significant class shall be contained in it's own file. The
-declaration of class gr_foo shall be in gr_foo.h, the definition in
-gr_foo.cc.
-
-
-
-* Storage management
-
-Strongly consider using the boost smart pointer templates, scoped_ptr
-and shared_ptr. scoped_ptr should be used for locals that contain
-pointers to objects that we need to delete when we exit the current
-scope. shared_ptr implements transparent reference counting and is a
-major win. You never have to worry about calling delete. The right
-thing happens.
-
-See http://www.boost.org/libs/smart_ptr/smart_ptr.htm
-
-
-* Unit tests
-
-Build unit tests for everything non-trivial and run them after every
-change. Check out Extreme Programming:
-http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
-
-Unit tests should also be written for all examples. This should kill
-off the bit rot we've been plagued with.
-
-** C++ unit tests
-
-For C++ we're using the cppunit framework. cppunit has its bad
-smells, but it's mostly workable. http://cppunit.sf.net
-
-Currently each directory <dirname> contains files qa_<dirname>.{h,cc}
-that bring together all the qa_<foo> test suites in the directory.
-We ought to be able to automate this without too much trouble.
-
-The directory gnuradio-core/src/tests contains programs that run
-the tests. test_all runs all of the registered C++ unit tests.
-
-As far as I can tell, the cppunit TestFactoryRegistry maybe able to be
-tricked into doing what we want. As is, I don't think it's enough by
-itself, since there's nothing dragging the qa* files out of the
-library and into the program. I haven't tested out this idea.
-
-** Python unit tests
-
-We use the standard unittest package for unit testing of Python code.
-
-
-* Misc tips
-
-ccache, a compiler cache, can really speed up your builds.
-See http://ccache.samba.org/
-
-Be sure to create links for gcc and g++
+++ /dev/null
-Have configure check for correct version of SWIG.
-gr_swig checks, but doesn't set any variable that can be checked
-afterwards.
-
-Failure to find SWIG should disable build of scripting directory
-
-
-Have configure search for FFTW includes and libraries (use pkg-config
-to find them)
-
-Come up with a consistent naming strategy and implement it!
-
-make o'scope display fast enough
-
+++ /dev/null
-Eric Blossom <eb@comsec.com>
-Matt Ettus <matt@ettus.com>
+++ /dev/null
-#
-# Copyright 2004 Free Software Foundation, Inc.
-#
-# This file is part of GNU Radio
-#
-# GNU Radio is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2, or (at your option)
-# any later version.
-#
-# GNU Radio is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with GNU Radio; see the file COPYING. If not, write to
-# the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
-# Boston, MA 02111-1307, USA.
-#
-
-Welcome!
-
-This package is a collection of examples for the GNU Radio 2.x toolkit.
-
-They assume that at a minimum, you've got the gnuradio-core
-package installed. In addition, depending on what i/o devices you
-have, you may want to consider installing:
-
- gr-usrp : support for Universal Software Radio Peripheral (Rev 1)
- gr-audio-oss : sound card support using OSS
- gr-audio-alsa : sound card support using ALSA
- gr-audio-osx : sound card support for OS/X
- gr-mc4020 : Measurement Computing PCI-DAS 4020/12 A/D card
-
-
-You'll need to set your PYTHONPATH environment variable so that the
-GNU Radio toolkit and optional packages can be found by python.
-
-PYTHONPATH should include the path of the local site-packages
-directory. It has the general form:
-
- ${prefix}/lib/python${pythonversion}/site-packages
-
-If the above packages were installed using the default prefix
-(/usr/local) and you're using python 2.3, this should work:
-
- $ export PYTHONPATH=/usr/local/lib/python2.3/site-packages
-
-You may want to add this to your ~/.bash_profile or similar file.
-
-
-Once PYTHONPATH is set, you should be able to run any of the examples
-for which you have the required i/o devices.
-
-To ensure that your setup is sane, try this:
-
- $ python
- >>> from gnuradio import gr
-
-If this works, your PYTHONPATH is set correctly.
-
-
-Have fun!
-
-The GNU Radio team
-
-
+++ /dev/null
-* Standard command line options
-
-When building applications or examples, if your command has any of
-these options, please use the following short and long names:
-
-
-
- # General
-
- parser = OptionParser(option_class=eng_option)
-
- parser.add_option("-f", "--freq", type="eng_float", default=None,
- help="set frequency to FREQ", metavar="FREQ")
- parser.add_option("-g", "--gain", type="eng_float", default=None,
- help="set gain in dB (default is midpoint)")
- parser.add_option("-F", "--filename", type="string", default=None)
-
- # Audio devices
-
- parser.add_option("-I", "--audio-input", type=string, default="",
- help="pcm input device name. E.g., hw:0,0 or /dev/dsp")
- parser.add_option("-O", "--audio-output", type=string, default="",
- help="pcm output device name. E.g., hw:0,0 or /dev/dsp")
- parser.add_option("-r", "--sample-rate", type="eng_float", default=48000,
- help="set sample rate to RATE (48000)")
-
- # USRP specific
-
- parser.add_option("-R", "--rx-subdev-spec", type="subdev", default=(0, 0),
- help="select USRP Rx side A or B (default=A)")
- parser.add_option("-T", "--tx-subdev-spec", type="subdev", default=(0, 0),
- help="select USRP Tx side A or B (default=A)")
- parser.add_option("-d", "--decim", type="int", default=16,
- help="set fgpa decimation rate to DECIM (default=16)")
- parser.add_option("-i", "--interp", type="int", default=32,
- help="set fgpa interpolation rate to INTERP (default=32)")
- parser.add_option("-n", "--nchannels", type=intx, default=1,
- help="set number of channels to NCHANNELS (default=1)")
-
+++ /dev/null
-Eric Blossom <eb@comsec.com>
-Matt Ettus <matt@ettus.com>
-
See http://www.atsc.org for specifications. The most relevant ones
are XXX and YYY.
-
-To build this, you must already have built and installed
-gnuradio-core. Then if you're building from a tarball:
-
- $ ./configure
- $ make
- $ make check
- $ sudo make install
-
-If you're building from CVS, you'll need to use this sequence, since
-CVS doesn't contain configure or the generated Makefiles.
-
- $ ./bootstrap
- $ ./configure
- $ make
- $ make check
- $ sudo make install
-
-
-The doc directory is not built by default. This is to avoid spurious
-build problems on systems that don't have xmlto installed. If you
-have xmlto and its dependencies installed, you can build the html
-version of the howto article by cd'ing to doc and invoking make.
+++ /dev/null
-N.B. This is currently a work-in-progress and is not ready for use.
-
-Stay tuned. It should be ready in a couple of days...
-
+++ /dev/null
-Eric Blossom <eb@comsec.com>
+++ /dev/null
-Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002 Free Software
-Foundation, Inc.
-
- This file is free documentation; the Free Software Foundation gives
-unlimited permission to copy, distribute and modify it.
-
-Basic Installation
-==================
-
- These are generic installation instructions.
-
- The `configure' shell script attempts to guess correct values for
-various system-dependent variables used during compilation. It uses
-those values to create a `Makefile' in each directory of the package.
-It may also create one or more `.h' files containing system-dependent
-definitions. Finally, it creates a shell script `config.status' that
-you can run in the future to recreate the current configuration, and a
-file `config.log' containing compiler output (useful mainly for
-debugging `configure').
-
- It can also use an optional file (typically called `config.cache'
-and enabled with `--cache-file=config.cache' or simply `-C') that saves
-the results of its tests to speed up reconfiguring. (Caching is
-disabled by default to prevent problems with accidental use of stale
-cache files.)
-
- If you need to do unusual things to compile the package, please try
-to figure out how `configure' could check whether to do them, and mail
-diffs or instructions to the address given in the `README' so they can
-be considered for the next release. If you are using the cache, and at
-some point `config.cache' contains results you don't want to keep, you
-may remove or edit it.
-
- The file `configure.ac' (or `configure.in') is used to create
-`configure' by a program called `autoconf'. You only need
-`configure.ac' if you want to change it or regenerate `configure' using
-a newer version of `autoconf'.
-
-The simplest way to compile this package is:
-
- 1. `cd' to the directory containing the package's source code and type
- `./configure' to configure the package for your system. If you're
- using `csh' on an old version of System V, you might need to type
- `sh ./configure' instead to prevent `csh' from trying to execute
- `configure' itself.
-
- Running `configure' takes awhile. While running, it prints some
- messages telling which features it is checking for.
-
- 2. Type `make' to compile the package.
-
- 3. Optionally, type `make check' to run any self-tests that come with
- the package.
-
- 4. Type `make install' to install the programs and any data files and
- documentation.
-
- 5. You can remove the program binaries and object files from the
- source code directory by typing `make clean'. To also remove the
- files that `configure' created (so you can compile the package for
- a different kind of computer), type `make distclean'. There is
- also a `make maintainer-clean' target, but that is intended mainly
- for the package's developers. If you use it, you may have to get
- all sorts of other programs in order to regenerate files that came
- with the distribution.
-
-Compilers and Options
-=====================
-
- Some systems require unusual options for compilation or linking that
-the `configure' script does not know about. Run `./configure --help'
-for details on some of the pertinent environment variables.
-
- You can give `configure' initial values for configuration parameters
-by setting variables in the command line or in the environment. Here
-is an example:
-
- ./configure CC=c89 CFLAGS=-O2 LIBS=-lposix
-
- *Note Defining Variables::, for more details.
-
-Compiling For Multiple Architectures
-====================================
-
- You can compile the package for more than one kind of computer at the
-same time, by placing the object files for each architecture in their
-own directory. To do this, you must use a version of `make' that
-supports the `VPATH' variable, such as GNU `make'. `cd' to the
-directory where you want the object files and executables to go and run
-the `configure' script. `configure' automatically checks for the
-source code in the directory that `configure' is in and in `..'.
-
- If you have to use a `make' that does not support the `VPATH'
-variable, you have to compile the package for one architecture at a
-time in the source code directory. After you have installed the
-package for one architecture, use `make distclean' before reconfiguring
-for another architecture.
-
-Installation Names
-==================
-
- By default, `make install' will install the package's files in
-`/usr/local/bin', `/usr/local/man', etc. You can specify an
-installation prefix other than `/usr/local' by giving `configure' the
-option `--prefix=PATH'.
-
- You can specify separate installation prefixes for
-architecture-specific files and architecture-independent files. If you
-give `configure' the option `--exec-prefix=PATH', the package will use
-PATH as the prefix for installing programs and libraries.
-Documentation and other data files will still use the regular prefix.
-
- In addition, if you use an unusual directory layout you can give
-options like `--bindir=PATH' to specify different values for particular
-kinds of files. Run `configure --help' for a list of the directories
-you can set and what kinds of files go in them.
-
- If the package supports it, you can cause programs to be installed
-with an extra prefix or suffix on their names by giving `configure' the
-option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
-
-Optional Features
-=================
-
- Some packages pay attention to `--enable-FEATURE' options to
-`configure', where FEATURE indicates an optional part of the package.
-They may also pay attention to `--with-PACKAGE' options, where PACKAGE
-is something like `gnu-as' or `x' (for the X Window System). The
-`README' should mention any `--enable-' and `--with-' options that the
-package recognizes.
-
- For packages that use the X Window System, `configure' can usually
-find the X include and library files automatically, but if it doesn't,
-you can use the `configure' options `--x-includes=DIR' and
-`--x-libraries=DIR' to specify their locations.
-
-Specifying the System Type
-==========================
-
- There may be some features `configure' cannot figure out
-automatically, but needs to determine by the type of machine the package
-will run on. Usually, assuming the package is built to be run on the
-_same_ architectures, `configure' can figure that out, but if it prints
-a message saying it cannot guess the machine type, give it the
-`--build=TYPE' option. TYPE can either be a short name for the system
-type, such as `sun4', or a canonical name which has the form:
-
- CPU-COMPANY-SYSTEM
-
-where SYSTEM can have one of these forms:
-
- OS KERNEL-OS
-
- See the file `config.sub' for the possible values of each field. If
-`config.sub' isn't included in this package, then this package doesn't
-need to know the machine type.
-
- If you are _building_ compiler tools for cross-compiling, you should
-use the `--target=TYPE' option to select the type of system they will
-produce code for.
-
- If you want to _use_ a cross compiler, that generates code for a
-platform different from the build platform, you should specify the
-"host" platform (i.e., that on which the generated programs will
-eventually be run) with `--host=TYPE'.
-
-Sharing Defaults
-================
-
- If you want to set default values for `configure' scripts to share,
-you can create a site shell script called `config.site' that gives
-default values for variables like `CC', `cache_file', and `prefix'.
-`configure' looks for `PREFIX/share/config.site' if it exists, then
-`PREFIX/etc/config.site' if it exists. Or, you can set the
-`CONFIG_SITE' environment variable to the location of the site script.
-A warning: not all `configure' scripts look for a site script.
-
-Defining Variables
-==================
-
- Variables not defined in a site shell script can be set in the
-environment passed to `configure'. However, some packages may run
-configure again during the build, and the customized values of these
-variables may be lost. In order to avoid this problem, you should set
-them in the `configure' command line, using `VAR=value'. For example:
-
- ./configure CC=/usr/local2/bin/gcc
-
-will cause the specified gcc to be used as the C compiler (unless it is
-overridden in the site shell script).
-
-`configure' Invocation
-======================
-
- `configure' recognizes the following options to control how it
-operates.
-
-`--help'
-`-h'
- Print a summary of the options to `configure', and exit.
-
-`--version'
-`-V'
- Print the version of Autoconf used to generate the `configure'
- script, and exit.
-
-`--cache-file=FILE'
- Enable the cache: use and save the results of the tests in FILE,
- traditionally `config.cache'. FILE defaults to `/dev/null' to
- disable caching.
-
-`--config-cache'
-`-C'
- Alias for `--cache-file=config.cache'.
-
-`--quiet'
-`--silent'
-`-q'
- Do not print messages saying which checks are being made. To
- suppress all normal output, redirect it to `/dev/null' (any error
- messages will still be shown).
-
-`--srcdir=DIR'
- Look for the package's source code in directory DIR. Usually
- `configure' can determine that directory automatically.
-
-`configure' also accepts some other, not widely useful, options. Run
-`configure --help' for more details.
-
+++ /dev/null
-#
-# Copyright 2005 Free Software Foundation, Inc.
-#
-# This file is part of GNU Radio
-#
-# GNU Radio is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2, or (at your option)
-# any later version.
-#
-# GNU Radio is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with GNU Radio; see the file COPYING. If not, write to
-# the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
-# Boston, MA 02111-1307, USA.
-#
-
-This tarball contains a build tree with examples, Makefiles, etc
-for radio astronomy related applications.
-
-To build the examples from the tarball use the normal recipe:
-
- $ ./configure
- $ make
- $ make check
-
-If you're building from CVS, you'll need to use this sequence, since
-CVS doesn't contain configure or the generated Makefiles.
-
- $ ./bootstrap
- $ ./configure
- $ make
- $ make check
-
and implement transparent reference counting using the boost shared_ptr
templates.
-To build the examples from the tarball use the normal recipe:
-
- $ ./configure
- $ make
- $ make check
-
-If you're building from CVS, you'll need to use this sequence, since
-CVS doesn't contain configure or the generated Makefiles.
-
- $ ./bootstrap
- $ ./configure
- $ make
- $ make check
-
-
-The doc directory is not built by default. This is to avoid spurious
-build problems on systems that don't have xmlto installed. If you
-have xmlto and its dependencies installed, you can build the html
-version of the howto article by cd'ing to doc and invoking make.
initialization. http://sdcc.sourceforge.net
-# To get started...
-
-./bootstrap # if you're building from CVS
-
-./configure
-make && make check && make install
-
-
The high level interface to the USRP using our standard FPGA bitstram
is contained in usrp/host/lib/usrp_standard.h
projects / debian / gnuradio / commitdiff