Re: [Discuss-gnuradio] USRP on NetBSD, partly/mostly working now

[Eric Blossom]

On Fri, Dec 16, 2005 at 03:59:39PM -0500, Greg Troxel wrote:
> I have been building GNU Radio from CVS on NetBSD, with all the
> prereqs installed via pkgsrc.  I had a few minor problems which I'll
> list here in case they are useful to others.
> 
> I made a wiki node: http://comsec.com/wiki?NetBSD

Thanks.

> 
> 1) buildit assumes that everything is in /usr, or perhaps that
>    everything is in the compiler's default paths.

Yes.   ./configure --help says this:

    Some influential environment variables:
      CC          C compiler command
      CFLAGS      C compiler flags
      LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
                  nonstandard directory <lib dir>
      CPPFLAGS    C/C++ preprocessor flags, e.g. -I<include dir> if you have
                  headers in a nonstandard directory <include dir>
      CPP         C preprocessor
      CXX         C++ compiler command
      CXXFLAGS    C++ compiler flags
      CXXCPP      C++ preprocessor
      F77         Fortran 77 compiler command
      FFLAGS      Fortran 77 compiler flags

    Use these variables to override the choices made by `configure' or to help
    it to find libraries and programs with nonstandard names/locations.


> This isn't true on NetBSD.  I added

>    LDFLAGS="-R/usr/pkg/lib -L/usr/pkg/lib" CPPFLAGS="-I/usr/pkg/include"

Don't you see this problem with everything that builds using stuff
from /usr/pkg?  How do other packages handle it?

BTW, what's the -R ldflag do?  Path for shared library resolution?

>    to resolve this, but obviously that's not portable.  One could
>    argue that such flags for the prefix should be added automatically,
>    but it also might be that GNU Radio is being put in /usr/gnuradio
>    while boost, swig, etc. are in the standard place.

I don't know the rationale for installing in /usr/gnuradio.  We don't
install much in the top level, so I don't think it's namespace
pollution.

>    So, adding --use-prefix=FOO that adds flags for it (with -R on
>    systems that use -R) could be useful, or perhaps even doing this by
>    default per OS - buildit is meant to be maximally helpful, not a
>    paragon of virtue.

--use-prefix=FOO sounds OK to me.  

Please submit a patch that does what you want.  

> 2) GNU make is required in some cases.  We could fix the makefiles to
>    work with BSD make also, or far easier just make buildit switch on
>    platform to invoke GNU make (gmake on BSD, and surely present on
>    systems that have a hope of compiling the prereqs).

There aren't intended to be any GNU make dependencies.  
If there are, please let me know where, and if possible suggest a fix,
or better yet, a patch.

> 3) Some files are checked in that are written during the build.  I use
>    CVSREAD=t so that files in CVS are readonly, and then use ^X^Q to
>    edit them, which does cvs edit, saves a local copy of the repo
>    version, and often allows others to see who is editing what files.
>    So, I wonder if these files should not be checked in.  If that's
>    too difficult it would be nice for the build should chmod +w them.
> 
>    gnuradio-core/src/lib/filter/Makefile.gen
> 
>      After looking at this one, I see that it's difficult.  The
>      Makefile is missing a dependency for Makefile.gen on
>      generate_all.py, so removing Makefile.gen has no way to rebuild
>      it, plus make chokes on the missing unconditional include.  Also,
>      Makefile.gen is unconditionally included.  Perhaps creating
>      Makefile.gen from src/lib before descending might avoid this.

Part of the nastiness is that automake handles the includes
at ./bootstrap time (that's when Makefile.in is generated from Makefile.am).
Builds from tarballs use the pre-generated Makefile.in's.

   ./bootstrap ==>   Makefile.am --> Makefile.in
   ./configure ==>   Makefile.in --> Makefile

I've got some evil Makefile.am code in a few places that forces the
include at make time, but it's pretty hideous (and fragile), and won't
work with versions of make that don't natively implement include.
Not sure how to resolve this issue.  Having an automake feature that
specified "include this file at make time" would be great.
[There must be some make somewhere that doesn't implement include]

>      It would be nice if the generated file had the date and hostname
>      of generation as well as RCD Ids of the generator code.

Good idea.  Please submit patches.  The code is almost certainly
called "gen<something>" and in almost all cases is in the same
directory as the generated code.

>    gnuradio-core/src/lib/general/Makefile.gen
> 
>      Same issue I think.
> 
>    src/lib/swig/gnuradio_swig_bug_workaround.h
> 
>      If this is deleted, make regenerates it with no issues.  So
>      perhaps this can simply  be deleted from CVS.

Thanks.  I deleted gnuradio_swig_bug_workaround.h from CVS.

> With that, and calling buildit with --prefix=/usr/gnuradio, I was able
> to build
> 
>  usrp gnuradio-core gr-usrp gr-audio-oss gr-wxgui
> 
> and am able to run the USB benchmark (4 MB/s via an NEC cardbus ehci,
> as good as has been reported on NetBSD), the oscope and fft.

Yeah!

> I could run usrp_nbfm_rcv after making a symlink from /dev/dsp to /dev/sound,
> and commenting out the following line
> 
>   self.fmrx.squelch.set_threshold(threshold_in_db)
> 
> The audio doesn't sound right, I think due to USB lossage, but I do
> hear quieting.
> 
> I have the EHCI spec on my reading pile...
> 
> -- 
>         Greg Troxel <address@hidden>

Thanks for all the input!

Eric