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

[Berndt Josef Wulf]

On Tuesday 09 November 2004 09:59, Tom Huppi wrote:
> Hi All,
>
[...]
> 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.

Good to know, thanks your enlightment.

> 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.

"make distclean" will take care of this. All I do is run "make distclean",
"bootstrap", "configure" after modifying any of the fundamental autoconf 
files.

cheerio Berndt

pgpQshW3n_4lo.pgp
Description: PGP signature