automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Splitting "make check" into separate build and run targets


From: Stefano Lattarini
Subject: Re: Splitting "make check" into separate build and run targets
Date: Wed, 21 Nov 2012 11:41:18 +0100

On 11/20/2012 04:06 PM, Björn Stenberg wrote:
> Stefano Lattarini wrote:
>> First, a smaller nit:
>>
>> -check-TESTS: $(TESTS)
>> +AM_RECURSIVE_TARGETS += buildtest runtest
>> +
>> +buildtest-TESTS: $(TESTS)
>> +
>> +check-TESTS: buildtest-TESTS
>> +             $(MAKE) $(AM_MAKEFLAGS) runtest-TESTS
>> +
>> +runtest-TESTS:
>>         @failed=0; all=0; xfail=0; xpass=0; skip=0; \
>>
>> With this, you force an extra recursive make invocation over every
>> user.  Now that we are suggesting to move towards non-recursive make
>> setups, this kind of changes is deprecated, and definitely unfit for
>> the Automake's core.
> 
> I am not aware of another way to specify sequential dependencies to
> a target.
>
Me neither.  In Automake-NG, we play some dirty tricks to avoid extra
recursions, but they makes heavy use of GNUmake-specific features.

> We could set runtest-TESTS as a second dependency for check-TESTS,
> but that would break with "make -j".
>
Which is quite unacceptable.

> Do you have a suggestion?
>
Nothing new, no.

>> In addition, and more to the point, the serial testsuite driver is
>> deprecated, and kept in maintenance-mode only.  If you want your
>> change to be integrated into Automake, I suggest you aim for the
>> parallel testsuite.  But I'm not sure that the semantic you want
>> will be as easy to implement there as it was for the serial tests.
> 
> Unfortunately, I need this split in the serial driver too.  I am
> working on packaging the test suites of all packages in a whole
> linux distribution, a significant percentage of which use the
> serial testsuite driver.
>
Ah, OK.

> Rewriting all test suites to use the parallel driver is just not
> feasible.
> 
I absolutely agree.

I fear your best course of action for the moment is to find a way to
integrate the trick I already suggested (or more advanced versions of
it, if yu come up with them) in your build setup.

Regards,
  Stefano




reply via email to

[Prev in Thread] Current Thread [Next in Thread]