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