Re: [cdt-dev] Antwort: [Newsletter] Re: CMake support in Eclipse CDT

[Doug Schaefer <dschaefer@xxxxxxx>]

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 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.

>Anyway, the binaries names are in CMakeCache.txt (cmake editable users
>settings) not in CMakeLists.txt (the meta build script).
>I can provide a parser for CMakeCache.txt incl. tests, if you need one.
>
>> From the cmake_compile_commands file, I get the compiler name, its
>>options
>> which can be parsed by the same code as the build output parser.
>> 
>> There is still a loop at one place:
>> Especially on Windows, cmake may not find the compiler itself or the
>>make
>
>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.

>
>> 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.

> 
>
>> For me/us it's very important to support cross compiling for different
>> architectures, that's where the cmake toolchain files come into the
>>game.
>
>Yes, cmake`s toolchain files [1] are the key here.
>
>Martin
>
>[1} http://www.vtk.org/Wiki/CMake_Cross_Compiling

Ah, yes. That¹s the one. Thanks! Looks like we could generate that with
the knowledge of the toolchain path, etc.

>
>-- 
>Cd wrttn wtht vwls s mch trsr.
>
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.eclipse.org/mailman/listinfo/cdt-dev