[Discuss-gnuradio] autoconf tricks (Was:...Building usrp module and firmware

[Tom Huppi]

Hi All,

I became aware of and interested in GNURadio a few days ago.  I
should probably keep my mounth shut for a time longer but...

The configure script does 'store the values at configure time.'
When configure is executed, it determines the values and stores
them in a _sed script_ called config.status, then as a final
phase, it executes this sed script to edit the Makefile.in files
(changing them into (ugly) Makefiles.)

Knowing this, it is handy to simply edit the config.status script
and re-execute it (as opposed to editing the Makefiles.)
Obviously, this is a testing only technique, but it saves the
hasssle of re-running the configure script, and also tells you
what you want the configure script to find, or at least it tells
that if the configure script were to find -I/path/to/foo on your
system, the build wouldn't fail.

Going further, Eric is unhappily correct that writing a new M4
macro or finding an existing one which does the right thing is the
correct course of action.  When hacking the configure.in, don't
forget to trash the config.cache file regularly, and do note that
the aclocal.m4 can become a consideration when adding or changing
macros.

Conceptually, fooling with the configure system is (or should be)
a small-ish part of the development process.  For this reason,
autoconf optimizes certain things at the expense of others.  In
the case of config.cache, the speed of execution is thought more
important than the ease of config system maintanance, thus, the
hassle of remembering to remove it or worse, trying to understand
when it's removal is necessary.  I've seen it burn and turn off a
lot of developers which is a shame.  That's my take on things at
least.

Thanks,

 - Tom


On Mon, 8 Nov 2004, Eric Blossom wrote:

> On Tue, Nov 09, 2004 at 02:43:24AM +1030, Berndt Josef Wulf wrote:
> > G'day,
> >
> > The autoconf system of the usrp module fails to find usb.h declaration file
> > which is part of the libusb package. Although set correctly in the Makefiles
> > created by autoconf, it fails to use the CFLAGS and LDFLAGS environment
> > variables at compile and link time.
>
> It should use CCFLAGS (not CFLAGS) and I'm pretty sure configure stores
> the values in effect at configure time for use in the Makefiles.  Be
> sure that you either export them explicitly, or export them on the
> command line:
>
>   $ CCFLAGS=-I/my/path/to/includes ./configure
>
> You may also want to test with CPPFLAGS for the -I options.
>
> > I also noted that usrp depends on packages libusb, boehm-gc and sdcc.
>
> Yes on libusb and sdcc.
>
> Our code doesn't depend on boehm-gc.  What's the source of the dependency?
>
> > The  building process progressed successfully after the installation of all
> > missing dependencies and manual manipulation of the relevant Makefiles. No
> > warnings were given to notify the user about missing packages.
>
> Please fix config/usrp_libusb.m4 and submit a patch.  It looks like
> AC_CHECK_HEADERS([usb.h]) should have AC_MSG_ERROR in the
> action-if-not-found case.
>
> In configure.ac replace...
>
> dnl check for firmware cross compilation tools
> dnl check for SDCC 2.4.0 (FIXME, actually check!)
> XCC='sdcc -mmcs51 --no-xinit-opt'
> XAS='asx8051 -plosgff'
>
> ... with code to perform the check and submit a patch.
> You'll probably want to write a new m4 macro [GR_CHECK_SDCC(version)] that 
> uses
> AC_CHECK_PROG and also something that parses the output of "sdcc -v"
> for the version number.
>
> > Would it be possible force autoconf to use the CFLAGS and LDFLAGS 
> > environment
> > during the configuration process or even better extend the configure option
> > arguments to include --with-extra-includes and --with-extra-libs, and also
> > check for all dependencies, such as sdcc and boehm-gc raising an appropriate
> > warning message informing users of the missing dependency?
>
> I'm pretty sure configure stores the values of CCFLAGS, CPPFLAGS, CFLAGS 
> (which
> we don't use) and LDFLAGS at configure time.  See comments above about
> exporting them.
>
> > Are "usrp" and "gr-usrp" the only modules required for the USRP Board 
> > specific
> > part of GnuRadio? If so, I'm ready and set to go. All I need now is a
> > board... :)
>
> Yes.  Though there may be some usb hacking required to get full
> performance under NetBSD (the equivalent to
> usrp/host/lib/fusb_linux.{h,cc} for NetBSD.)  Of course you won't know
> until you get a board...
>
>
> Matt, can you give us an update on board availability, por favor?
>
>
> > Well, not quite! I still will have to find and read all relevant
> > documentation.
>
> Documentation outside of that in the code is pretty sparse on usrp and
> gr-usrp.  If you're going to start code reading, I suggest that you
> start with usrp/host/lib/usrp_standard.h  It's the top level interface, and
> for most users the only thing they'll have to worry about.
>
> In gr-usrp take a look at gr-usrp/src/usrp1*.{h,cc}
> It's a thin wrapper that glues usrp_standard into GNU Radio.
>
> Eric
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>