bug-38236.tst (was Re: HAVE_FFTW macro)

[Daniel J Sebald]

On 03/17/2013 04:29 AM, John W. Eaton wrote:
> On 03/17/2013 12:20 AM, Rik wrote:
> > On 03/16/2013 12:52 AM, address@hidden wrote:
> > > > Is something being overlooked there?
> > > What does
> > >
> > > octave_config_info ("features")
> > >
> > > show? This is a list of all the HAVE_X macros, with the common "HAVE_"
> > > part omitted. On my system, it has FFTW3, but not FFTW, so it looks
> > > like the testif check is wrong.
> > Dan,
> >
> > The problem seems to be that not all #defines are captured in the new
> > "features" keyword. The definition for HAVE_FFTW is in configure.ac in
> > the
> > AH_BOTTOM macro which means it is copied to the bottom of config.h.
> >
> > /* Octave is currently unable to use FFTW unless both float
> > and double versions are available. */
> > #if defined (HAVE_FFTW3)&& defined (HAVE_FFTW3F)
> > #define HAVE_FFTW
> > #endif
> >
> > I wasn't following closely what jwe did when he added the "features"
> > keyword, but hopefully it is simple to fix.
>
> OK, I see the problem now.
>
> The new list is generated from the config.h file by
> libinterp/config-features.sh, and that script finds anything that looks
> like #define HAVE_, so it picks up the #define FFTW regardless of the
> values of HAVE_FFTW3 and HAVE_FFTW3F and adds it to the struct with a
> corresponding value of 1. Anything that matches #undef HAVE_ is also
> inserted in the struct with a value of 0.
>
> I checked in the following change so that we don't pick up these extra
> values that are defined conditionally. Using a separate header file for
> AH_BOTTOM is recommended by the autoconf manual anyway.
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/306e0ac231d0
>
> Then I realized that FFTW would not be set to 1 in the features list
> unless it was added to the config.h file somehow, so then I made another
> change so that it is defined in config.h the same as other HAVE_X macros.
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/5293cee91891

I see from the changeset how autoconf works now.  Thanks.

Well, all the check tests look good except for fftfilt for which Ed 
Meyer has a fix and the following unknown failure:

> > > > > processing bug-38236.tst
  ***** test
 u_vr
!!!!! test failed
'vr' undefined near line 1 column 37

The bug in this case is that df_vr is a script in a file (not a 
function, but a script) and under the conditions isn't creating a local 
variable vr so the test believes vr is undefined.

Are these "bug-xxxxx" code hunks to be reminders of some sort (in which 
case, why not use xtest instead of test)?  Or are they something to 
check recently fixed bugs to make sure everything is working out in the 
field?

Dan

PS: Should bug-31371.tst be in its own sub-directory?