[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Don't build tests as part of plain "make"

From: Max Bowsher <maxb_at_ukf.net>
Date: 2004-04-02 22:30:52 CEST

Greg Hudson wrote:
> On Fri, 2004-04-02 at 14:59, C. Michael Pilato wrote:
>> Greg Hudson <ghudson@MIT.EDU> writes:
>>> -1. This comes up every so often; the problem is that "make
>>> CFLAGS=-g" (or whatever) followed by "make check" will compile the
>>> test programs with different flags than the user intended.
>> Is it so much to ask of a user that if they intend to tweak their
>> build of Subversion corestuffs, they tweak their build of the tests
>> similarly?
> It's not the end of the world, no. But "make check" isn't supposed to
> build the tests; it's supposed to run them. "make all" (or just "make"
> for short) is supposed to build the tests, since, you know, they're part
> of "all".
> If it took a long time to build the tests, I'd be willing to bend, but I
> just don't see the point. Unnecessary optimization is the root of all
> evil. (Okay, 65% of all evil.)

I see things a bit differently to you. I consider this optimization
worthwhile, not unnecessary, because watching make compile stuff you have no
intention of using is annoying.

Also, I interpret "make check" as "run the tests, including doing any
necessary preparatory work".

"all" has become the traditional name for the default make target, even when
it doesn't actually do everything. I understand it as "all of the subversion
software", not "all of the subversion software, plus more stuff to verify
that all of the subversion software works correctly".

If someone does want to build the tests at the same time as "all", they can
do "make all test fs-test". If wanted, I will make a target "tests" that is
defined to "test" or "fs-test" as appropriate.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 2 22:31:44 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.