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

[Marcel Loose]

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.
> 
> 
> _______________________________________________
> 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

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.