On Sunday, December 06, 2015 20:25:18 Doug Schaefer wrote:
> On 2015-12-06, 8:35 AM, "cdt-dev-bounces@xxxxxxxxxxx on behalf of Martin
> Weber" <cdt-dev-bounces@xxxxxxxxxxx on behalf of
>
> fifteenknots505@xxxxxxxxx> wrote:
> >Am Freitag, 4. Dezember 2015, 14:59:07 schrieb Doug Schaefer:
> >> From: <cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>>
> >>
> >>on
> >>
> >> behalf of
> >> "Martin.Runge@xxxxxxxxxxxxxxxxx<mailto:Martin.Runge@xxxxxxxxxxxxxxxxx>"
> >>
> >> In the cmake4cdt plugin, I use the output of cmake
> >> -DCMAKE_EXPORT_COMPILE_COMMANDS=on to feed the include paths into the
> >> indexer. I just checked that cmake also produces the
> >>
> >>compile_commands.json
> >>
> >> file when using the ninja generator (at least on linux).
> >
> >AFAIK, compile_commands.json is written when the cmake-makefle generator
> >or
> >ninja-generators is used. Not sure whether the file is written when the
> >mingw,
> >msys or cygwin generator is used.
>
> We¹re at the point now that we should probably find out exactly where it¹s
> generated or not.
I'm relatively sure that it works for all makefile and ninja generators.
> >> I do not need to parse the CMakeLists.txt (I dont't think it's
> >>feasible) nor
> >> CMakeCache.txt files (may be feasible).
> >> We may need to parse the CMakeLists file for other reasons, mainly
> >>finding
> >> the binaries to launch. But we¹ll deal with that when we get there.
> >
> >Doug, which binaries to launch? Compilers and linkers? These are launched
> >by the actual build tool (make, ninja, etc).
>
> No I mean the build output. The things we¹re going to launch at launch
> time for run, debug, etc. Mainly all the add_executable()¹s.
To do that reliably, CMakeLists.txt need to be parsed and the commands need to be executed. Below a fictional example in almost correct cmake syntax (usage of cmake in KDE4 is quite similar to this):
e.g. in a fictional KDEInit.cmake:
function(kde4_add_kdeinitexecutable _name)
set(targetName "kdeinit_${_name}")
add_executable(${targetName} ...source files)
...do more stuff
endfunction()
then later on in a CMakeLists.txt:
cmake_minimum_required(VERSION 3.1.2)
find_package(KDEInit)
set(targets kate kwrite konsole)
foreach(tgt ${targets})
kde4_add_kdeinit(${tgt} ...source files)
endforeach()
To figure out that this produces the executables kdeinit_kate, kdeinit_kwrite and kdeinit_konsole, CDT has to execute
- cmake_minimum_required (e.g. search rules may have changed with different versions/cmake policies)
- find_package() (and all its rules how it searches files)
- set() (with all its special case behaviours)
- foreach()/endforeach()
- function()/endfunction()
> >Maybe I missed something here, but why do you need name of the compiler?
> >If
> >you want to feed the indexer, you need its built-in pre-processor defines
> >and include paths.
>
> For GCC at least, we get the built-ins by invoking the compiler with the
> right magic options. So we need to know the path to the compiler to do
> that.
Yes.
Alternatively you can get the defines and include dirs from cmake. :-)
> >> path to the compiler prior to the call to cmake -> it may not be
> >>sufficient to parse the compiler's name out of any cmake output.
> >
> >Forget about parsing cmake output (when generating build-scripts) if
> >cmake is invoked by the launcher provided by CDT!
> >cmake spits out messages on both stderr (unbuffered) and stdout
> >(buffered).
> >Most of these messages span multiple lines. This looks fine in a console
> >windows, but the launcher provided by CDT does not synchronize writes to
> >stdin/-err, so your parser will see a crazy mixture of lines originating
> >from
> >messages written to stdout intertwined with lines written to stderr.
>
> It¹s definitely an objective to eliminate the need to parse build output
> as much as possible. So far, I¹ve been successful at that with the Qt
> qmake -E support. At worse, if we¹re using make, we can do a separate pass
> running make -n -B to spit out the build commands without doing the build
> and parse that.
Sorry for repeating, but cmake is *designed* to provide such information to the IDE, in the format the IDE expects.
I.e. either using generators or using the "buildsystem metadata".
Alex
|