[Top][All Lists]
[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
- Splitting "make check" into separate build and run targets, Björn Stenberg, 2012/11/15
- Re: Splitting "make check" into separate build and run targets, Stefano Lattarini, 2012/11/15
- Re: Splitting "make check" into separate build and run targets, Björn Stenberg, 2012/11/16
- Re: Splitting "make check" into separate build and run targets, Stefano Lattarini, 2012/11/17
- Re: Splitting "make check" into separate build and run targets, Björn Stenberg, 2012/11/19
- Re: Splitting "make check" into separate build and run targets, Stefano Lattarini, 2012/11/19
- Re: Splitting "make check" into separate build and run targets, Björn Stenberg, 2012/11/20
- Re: Splitting "make check" into separate build and run targets,
Stefano Lattarini <=