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

Attachment: PGP.sig
Description: This is a digitally signed message part

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to