[CMake] CTest: use 'make -k' instead of 'make -i'

[Michael Wild]

On 27. Oct, 2010, at 9:54 , Marcel Loose wrote:

> On Tue, 2010-10-26 at 11:46 +0200, Marcel Loose wrote:
>> On Mon, 2010-10-25 at 17:30 +0200, Michael Wild wrote:
>>> On 25. Oct, 2010, at 17:14 , Tyler Roscoe wrote:
>>> 
>>>> On Mon, Oct 25, 2010 at 04:54:41PM +0200, Michael Wild wrote:
>>>>> On 25. Oct, 2010, at 16:45 , Marcel Loose wrote:
>>>>>> Wouldn't it make more sense to use 'make -k' instead? 
>>>>> 
>>>>> Some weeks ago I also wanted to propose this, but then realized
> one
>>>>> important drawback of -k: Say, you have target B depending on A.
> If
>> A
>>>>> fails, nothing from B will be compiled, thus hiding programming
>> errors
>>>>> that will only show up once A is fixed. What needs to be fixed is
>> the
>>>>> error parser in CTest.
>>>> 
>>>> Marcel,
>>>> 
>>>> I think you can override this compiler flag with use of
>>>> CTestCustom.cmake or one of those override mechanisms.
>>>> 
>>>> Michael and everyone,
>>>> 
>>>> I think that use case is pretty narrow. If I know that B depends
> on
>> A
>>>> and I see that A failed, I'm going to take a pretty suspicious
> view
>> of
>>>> any build errors in B -- what if they were somehow caused by the
>> failure
>>>> in A?
>>>> 
>>>> Besides, doesn't -k satisfy your use case while removing the
>> confusing
>>>> and erroneous report of success caused by using -i?
>>>> 
>>>> Thanks,
>>>> tyler
>>> 
>>> 
>>> Problem is, not a single file from B will be compiled (if building
>> serial, that is). And I think that such errors are pretty common. Say,
>> somebody changes the implementation of A (not the interface!) and
>> introduces a compilation error there and somebody else messes with B.
>> Although compilation errors from B would still be informative (they
>> don't depend on the implementation of A, only its interface), they
> don't
>> show up until A is fixed, wasting potentially a lot of time.
>>> 
>>> I agree with you that it is a good thing to abort on first error
> when
>> doing interactive work, but on a dashboard I prefer to see the whole
>> picture and determine for myself whether a particular error is due to
>> another, earlier error or not.
>>> 
>>> And if you really must, you can do the override by setting the
>> CTEST_BUILD_COMMAND variable to e.g. "/usr/bin/make -k".
>>> 
>>> Michael
>>> 
>>> --
>>> There is always a well-known solution to every human problem --
> neat,
>> plausible, and wrong.
>>> H. L. Mencken
>>> 
>> 
>> Hi Michael,
>> 
>> If it's really the case that nothing from B will be compiled, then I
> can
>> understand the rationale of using 'make -i', instead of 'make -k'.
> But,
>> read my other mail as well.
>> 
>> Anyway, would it possible to let 'ctest' return with a non-zero exit
>> status when build errors occur? It would really help in situations
> where
>> 'ctest -D ExperimentalBuild' is used in a script. It means, though,
> that
>> 'ctest' cannot rely on the exit status of 'make' (because 'make -i'
>> always returns 0); it'll need to analyze its output. Any ideas on
> this?
>> 
>> Best regards,
>> Marcel Loose.
> 
> Hi all,
> 
> I would really like ctest to return with an error status when compiler
> errors occur. Should I enter an issue report for this?
> 
> Regards,
> Marcel Loose.

I think this would be best. I didn't look into the code, but I suspect that fixing the error parser would also fix this...


Michael

--
There is always a well-known solution to every human problem -- neat, plausible, and wrong.
H. L. Mencken

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://www.cmake.org/pipermail/cmake/attachments/20101027/0021cea8/attachment.pgp>