Email list hosting service & mailing list manager

means to disable tests Neil Van Dyke (11 Nov 2005 16:55 UTC)
Re: means to disable tests bear (11 Nov 2005 17:46 UTC)

Re: means to disable tests bear 11 Nov 2005 17:46 UTC


On Fri, 11 Nov 2005, Neil Van Dyke wrote:

>
>I'm fond of single-file libraries, and like to embed test cases within
>the libraries, with a simple way of disabling the test suite when the
>library is deployed (to free up some resources).

Me too.  The way I handle it is very unschemely, though.

I put it between #ifdef and #endif lines in the source code.

I process Scheme files using CPP and make.  Multi-file projects
are concatenated according to make targets and #ifdef configuration
commands into a single "target" file which is loaded into the
system. This is ugly and it fails to win the advantages of separate
compilation,  but it's flexible, near universally available and
_means_the_same_thing_in_all_versions_of_scheme_ , so it's the
configuration control and module  system I use.  Anyway, I have
different makefile targets for "testbuild" and "interactivebuild"
and "releasebuild" -- and often even separate targets for testing
separate specific subsystems that include test routines and
accessors not needed in the general builds.

However, this goes way past just testing; configuration
control is actually a bigger problem.  And the fact that
the best solution I've found is at best an ugly hack is
telling, as far as I'm concerned, as to exactly how sticky
a problem it is.

I will be watching the module system proposal from the
R6RS committee with interest; although I wouldn't actually
suggest doing it the way I do it, if I feel that the module
system proposal doesn't allow the same flexibility and
unambiguity, odds are I won't be using it myself.

But on that tack, are we confident that this SRFI won't
be obsoleted instantly by the module system proposal that
presumably allows some kind of configuration control?

				Bear