From: David Abrahams (dave_at_[hidden])
Date: 2002-11-05 16:06:59
"John Maddock" <jm_at_[hidden]> writes:
> > Now that's just silly, and I daresay somewhat distressing. We went to
> > all this effort to provide a reasonably powerful programming language
> > in Jam which allows you to avoid writing the same thing over and over
> > again; you could clean this all up with a few lines of Jam code, and
> > instead you add a layer of scripting on top which generates the
> > "usual-quality" machine-generated code. I just can't understand why
> > that's preferable.
> Well because I understand shell scripts (and makefiles for that matter), a
> lot more thoroughly than I do the Jam language, sorry, but I'll tend to use
> whatever is quickest to put together :-(
Well, it shouldn't take a huge investment on your part to learn to
write and use something like:
rule regex-test ( name : sources + : libs * : args * : defines * )
defines += BOOST_REGEX_NO_LIB=1 BOOST_REGEX_STATIC_LINK=1 ;
: # test-files
: $(args) # additional args
: <define>$(defines) # requirements
: $(name) # test name
I started replacing all your stuff by uses of this, but it's
exceedingly tedious work to correctly unwind all the boilerplate
you've repeated, and I don't really have the time. Also, I don't have
the expertise to be sure I haven't broken something. You could
probably do this much faster than I.
> Better versions are always welcome though...
There you go.
1. $(SUFLIB) is unneccessary
2. $(SLASH) is unneccessary
3. You don't really need to use the input-files feature unless you're
planning to establish update dependencies on them. Since many of
your tests are just forcing input files into the test arguments
slot, I assume you don't care about dependencies, which is why I
left them out of the rule above. You could easily add another
argument to accomodate them.
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com