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