[CMake] Processing the output from CMake build

Wed Jul 15 15:34:36 EDT 2009

> 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.
This is correct.

> 1) On first invocation of CMake force the compiler to be yours:
> 
> $ CC=filecc cmake <any other usual argument>
I do not set CC. Actually I believe this is generally only available on
Linux and OSX but not under Windows.
Should setting the name of the compiler in the CMakeLists.txt not be enough?

> 2) SET(CMAKE_C_COMPILER_INIT filecc) before PROJECT macro call
>     in Your CMakeLists
Currently I'm using SET(CMAKE_CXX_COMPILER filecc) to set the compiler to my
wrapper.
Is it more appropriate to use CMAKE_C_COMPILER_INIT and what would be the
difference?

> Did you have a look at CTest+CDash,
> CTest produces report for
>   - Update
>   - Configure
>   - Build
>   - Test
> steps of a project.
Not yet but if they are as good as CMake is, I should probably have a look
at them.

Thank you for your comments and help.

-D

> -----Original Message-----
> From: Eric Noulard [mailto:eric.noulard at gmail.com]
> Sent: Wednesday, July 15, 2009 5:48 PM
> To: Dieter Oberkofler
> Cc: CMake at cmake.org
> Subject: Re: [CMake] Processing the output from CMake build
> 
> 2009/7/15 Dieter Oberkofler <doberkofler.lists at gmail.com>:
> >> 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