Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Antwort: [Newsletter] Re: Antwort: [Newsletter] Re: CMake support in Eclipse CDT

Hi

Regarding CMake and the compiler:

If both cmake and the compiler are in the PATH, like usually on Linux, Eclipse would not need to know about the toolchain itself. CMake would find the compiler and eclipse could read everything needed out of the compile-commands.json file (assumed that it turns out that we can rely on it).

But I saw at least on case (MinGW on Windows) where gcc was not in the PATH -> cmake did not find the compiler while generating the Makefile and aborted. In this case, Eclipse should set the environment before calling cmake to enable cmake to find gcc -> Eclipse needs to know the compiler.

Another solution would be to feed all these infos into CMake via the toolchain file. Usually, this is done for cross compilers which are mostly not inside PATH on Linux, too.

If Eclipse needs to know all the details about the toolchain, it can also generate a CMake Toolchain file for cross compiling.


I agree that parsing stdout/stderr of cmake is "not a good way". We should avoid it as much as possible, but for the CMake Error parser, someone has to read it. Marc-Andre also came across this when writing an CMake error parser: ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=476824 ).
By "parsing any CMake output", I ment the compile_commands.json, CMakeCache.txt or any other file generated by CMake. If there is a reliable way to get information stored in CMakeLists.txt from cmake itself, we should use it wherever possible.

Martin

 


Von:        Doug Schaefer <dschaefer@xxxxxxx>
An:        CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Datum:        2015-12-06 21:26
Betreff:        [Newsletter] Re: [cdt-dev] Antwort: [Newsletter] Re: CMake support in Eclipse CDT
Gesendet von:        cdt-dev-bounces@xxxxxxxxxxx






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

_______________________________________________
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




Content provided within this e-mail including any attachments, is for the use of the intended recipients and may contain Rohde & Schwarz company restricted information. Any unauthorized use, disclosure, or distribution of this communication in whole or in part is strictly prohibited. If you are not the intended recipient, please notify the sender by reply email or by telephone and delete the communication in its entirety.


Back to the top