From: Brad King (brad.king_at_[hidden])
Date: 2007-10-05 18:08:07
David Abrahams wrote:
> on Fri Oct 05 2007, Larry Evans <cppljevans-AT-cox-internet.com> wrote:
>> Another difficulty with CMake may be *related* to a difficulty with
>> the boost preprocessing library. I often had to use Make to specify
>> the compiler option (e.g. g++ -E) to produce the preprocessor output
>> before I could understand why my preprocessing wasn't doing what I
> You couldn't invoke g++ -E directly? That's what you have to do with
> BB unless something has changed.
FYI, with CMake's generated makefiles you can run
in a directory that has a target using myfile.o and you will get the
preprocessed output generated with all the flags used to compile the
object file. The produced output will be in a file named myfile.i
located next to its corresponding object file.
>> I also ran the output through a filter to strip out the
>> output before the preprocessing done by my macros occurred.
>> However, I'm wondering if the Makefiles produced by CMake have the
>> same or similar traceback feature to allow debugging.
> I don't know the answer, but there's a big difference here: you're the
> one who writes (and has to debug) code that uses the preprocessor
> library. Someone else writes (and has to debug) Cmake. I wouldn't
> even suggest the use of Cmake if I thought we would have to debug it.
> That said, it might be useful to see some relationship between the
> output of make and the build descriptions in CMakeLists.txt files; I
> don't know if Cmake does anything for you there.
There is currently no explicit attempt to put information in the
makefiles about what cmake code caused each line to be generated.
However each target's make rules are in a makefile whose location
(directory name) can be used to deduce the location of the ADD_* command
that was used to create it.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk