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