| Re: [cdt-dev] Antwort: [Newsletter] Re: CMake support in Eclipse CDT |
|
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
|