Re: [Discuss-gnuradio] usrp* example consolidation

[Eric Blossom]

On Sat, Feb 26, 2005 at 12:17:40PM -0000, Robert McGwier wrote:
> Eric:
> 
> For many of the new directories, I had to do touch configure.ac
> and buildit manually.  for-all-dirs would fail, period.
> gr-gsm-vocoder is a particularly example.  It would never get
> passed the "no makefile.in"  error with for-all-dirs.  I
> tried doing
> 
> for-all-dirs touch configure.ac
> 
> this worked on some directories but I would still get a makefile.in
> failure always in the gsm vocoder directory.  On those directories,
> if I went into the directory and did touch configure.ac and then
> used ../buildit, it always worked!  Single exception:  gr-usrp.
> There I had to do touch configure.ac and ../buildit 3 times and
> then it finally made.

When you did the touch, did the time of the file reflect your current
system time?  I would expect it to.  I'm asking just want to rule out
(unlikely) differences in the behavior of touch on SUSE.

The fact that you had to do it three times makes me think that enough
time had passed that the timestamp on configure.ac was no longer in
the future.

> This is not a time shift problem, this is a bug.

I agree it's a bug.  (I do think it has do to with time/timestamps.)
I'll check around on the GNU maintainers list and see how
folks are handling this.

> I have a true SMP machine (dual Athlon MP).  Can this have anything
> to do with it?  SUSE 9.2 and for those packages that the build tools
> complained I had no version, or not the "latest version", I went to
> the respective project sites and got the latest and greatest.

I build on a dual Althlon too, so I don't think this is the problem.

> While I am whining, what is with this underquoted AM_PATH_CPPUNIT
> and underquoted AM_PATH_AVIFILE warning message?  Is it serious? What
> exactly does it mean?

There are changes underway with autoconf/automake that changes (or
begins to enforce) a convention on how the names and definitions of
macros are supposed to be quoted.  The macros are written in m4.  This
warning is so that the maintainers of the relevant packages will fix
their macros.

It's not a problem (yet).

I don't see the AM_PATH_CPPUNIT warning on my system.  We're
distributing a fixed version in our config subdirectory.  I'll check
the upstream cppunit package, maybe it hasn't been updated.  On my
system the warnings are all about stuff in /usr/share.  I don't
control those, and at least on my system, we're not invoking the ones
with warnings.


address@hidden gr-gsm-fr-vocoder]$ ./bootstrap
/usr/share/aclocal/vorbis.m4:9: warning: underquoted definition of 
XIPH_PATH_VORBIS
  run info '(automake1.8)Extending aclocal'
  or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal
/usr/share/aclocal/pilot-link.m4:1: warning: underquoted definition of 
AC_PILOT_LINK_HOOK
/usr/share/aclocal/ogg.m4:8: warning: underquoted definition of XIPH_PATH_OGG
/usr/share/aclocal/libart.m4:11: warning: underquoted definition of 
AM_PATH_LIBART
/usr/share/aclocal/imlib.m4:9: warning: underquoted definition of AM_PATH_IMLIB
/usr/share/aclocal/imlib.m4:167: warning: underquoted definition of 
AM_PATH_GDK_IMLIB
/usr/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK
/usr/share/aclocal/gdk-pixbuf.m4:12: warning: underquoted definition of 
AM_PATH_GDK_PIXBUF
/usr/share/aclocal/g-wrap.m4:7: warning: underquoted definition of 
AC_GWRAP_CHECK_GUILE
/usr/share/aclocal/g-wrap.m4:23: warning: underquoted definition of 
AM_PATH_GWRAP
/usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of 
AM_PATH_AUDIOFILE


Eric