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

[Marcel Loose]

On Wed, 2010-10-27 at 11:00 +0200, Michael Wild wrote:
> 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
> 

OK,

Here http://public.kitware.com/Bug/view.php?id=11368 it is.

Regards,
Marcel Loose.