2009/7/15 Dieter Oberkofler <[email protected]>: >> But I do not need that feature, would you explain why >> you need the 1 file compiled - 1 file error mapping? > Generally speaking to keep track of each individual file status. This > especially useful, when dealing with compiler warnings that would simply > "disappear" (after a new build when only looking at a single build log) > without an individual log file for each file to compile.
OK I see for that one. This is way to know that the last compilation/link of that file gave some message. > The second reason is more a convenience/performance reason when loading the > errors for a given source file. > But maybe I'm also just used to it (I was working like this for more than 15 > years) and there is better way to do this? I usually correct compiler error/warning in FAFC order First to Appear First Corrected. This done until there is no more error/warning thus I usually do not correct ALL error at once, but only the first ones I see. >> Could you point us to the feature request link? > http://public.kitware.com/Bug/view.php?id=6776 OK. >> Did you provide a patch? > No, I would now really know how to solve this. Since the build is done by the target generator (make, nmake, etc...) I would say the change should be made in each generator you are wanting to support/use beginning with Makefile generator. To be clear "make" (CMAKE_BUILD_TOOL) is invoking the compiler/linker not "CMake". >> Since you told us the wrapper solution seems to work why do you need >> more? > It is just very complicated and a little hard to use and I would prefer to > stick with the build-in rules to compile and link if possible. I don't get it you may well build a compiler wrapper scripts/application and keep your CMakeLists.txt as-is? Let's say that your wrapper for the C compiler is called filecc, then you may 1) On first invocation of CMake force the compiler to be yours: $ CC=filecc cmake <any other usual argument> 2) SET(CMAKE_C_COMPILER_INIT filecc) before PROJECT macro call in Your CMakeLists as explained here: http://www.cmake.org/Wiki/CMake_Useful_Variables#Compilers_and_Tools your filecc wrapper should do the appropriate file redirection in order to create your wanted files. >> vi /home/eric/workspace/certi-HEAD/libCERTI/TSCClock.cc +15 >> will open the concerned file at the appropriate place. > I understand that this is the common way to do this but how are you dealing > with the following: > - You do no longer see the build results on your screen Like I said before I usually only take care of the first say 5 or 10 errors, after that compilation should stop, thus the screen is not flooded with error messages. If ever there is too much messages (warning when switching to a standard-picky compiler) I do redirect the whole output into a single and browse it afterwards. > - A 2nd build does no longer report the warnings from the 1st one because > files no longer need to be compiled make clean; make but I'm ok this one is interesting. > - The build itself is distributed and the results are not visible on your > screen Then I have a single file by remote build, much like CTest does in its report, then browse the report file for fixing. Did you have a look at CTest+CDash, CTest produces report for - Update - Configure - Build - Test steps of a project. The report may then be published to a dashboard like CDash, see for example: The CMake Dashboard http://public.kitware.com/dashboard.php?name=cmake and an example of report with warning (during build, either compiler or liker error): http://www.cdash.org/CDash/viewBuildError.php?type=1&buildid=378731 http://www.cdash.org/CDash/viewBuildError.php?type=1&buildid=378732 May be you can use CTest locally and use the Build.xml file produced by ctest?? This is a single (but structured file), or may be ctest can be your build tool since it already collects the build error/warning in order to build the Build.xml file? > - I cannot remember about vi but the editors I use allow you to see the > source file and the errors next to each other. This is also supported when > having a unique build log file but takes (a lot) longer to be processed when > working on large projects This is a matter of taste and usage but I would say that most project should have small amount of compiler error/warning EVEN IF they are large. If they don't may be you are only concerned by a reasonable subset you have to fix, thus fast-advancing to the portion of the big log file you are interested in may be manageable. > I hope, to have explained myself a little better and would be happy to learn > that what I'm doing is just no longer needed. Yes you do. Now I think (my personal opinion though) that your problem of seeking compiler/linker error/warning is common, that's pretty much [part of] the job of all continuous integration tools http://en.wikipedia.org/wiki/Continuous_integration including CDash/CTest. However the solution to have the 1 -to -1 file mapping is not :-) In the end I think that: 1) writing a compiler wrapper is doable and should give you the expected result 2) may be giving a look at other ways to do the same task would be interesting for you too (whatever your final way to go is) hope this helps -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org _______________________________________________ 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
