Re: How does ./configure interact with the demo directory?

[Hans-Bernhard B. <br...@ph...>]

On Wed, 21 Apr 2004, Lars Hecking wrote:

> Ethan Merritt writes:
> > While the dust is settling from the version 4 release,
> > I thought I'd have a go at adding a couple of new demos
> > and cleaning up the auto-generation of html demos.
> > 
> > Is there there some way to make the generation of
> > demos (e.g. their inclusion in 'all.dem' or 'make html')
> > depend on the options selected in ./configure?
> > 
> > For example, if you say
> > 	./configure --disable-filledboxes
> > then it should not try to exercise fillstyle.dem
>  
>  gnuplot does not have a proper test suite as such. A proper test suite,
>  GNU auto* style, would exercise gnuplot features, and print PASS/FAIL,
>  no graphics. I am not sure this can be done with gnuplot in the first place.

The "obvious" way would be a regression suite.  E.g. run each demo
through

	GNUTERM=postscript gnuplot foo.dem \
	  | filter_out_times_and_dates \
          | diff -q - foo_ref.ps 

and check the return status of diff to print PASS/FAIL.

>  Using the demos for 'make check' was my original attempt at something
>  that closely resembles a test suite.

I thought so.

> Hans-Bernhard Broeker writes:
> > On Mon, 19 Apr 2004, Ethan Merritt wrote:
> [...]
> > For html, you can quite certainly use automake conditionals to change the
> > list of html files being run.
> 
>  I believe this might unnecessarily complicate matters. The all-local.dem.in
>  approach can easily be done with configure, once the demo that require
>  specific configure options have been identified.

If we insert some more settings into configure.in, right.  config.status
itself doesn't do conditionals on translating .in files into something
else, it just does replacements. 

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.