On Saturday, October 10, 2015 00:27:30 Doug Schaefer wrote:
> From: Alexander Neundorf <neundorf@xxxxxxx<mailto:neundorf@xxxxxxx>>
> Date: Friday, October 9, 2015 at 4:46 PM
> To: Doug Schaefer <dschaefer@xxxxxxx<mailto:dschaefer@xxxxxxx>>
> Cc: "cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>"
> <cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>> Subject: Re: [cdt-dev]
> Antwort: CMake support in Eclipse CDT
>
> On Friday, October 09, 2015 20:33:39 Doug Schaefer wrote:
> > I’ll have to top post this since Outlook is mucking up the lines.
> >
> >
> >
> > Essentially I don’t want CMake to generate .project and .cproject files. I
>
> I understand this.
>
> Still this is useful in the case that a CDT-user wants to use CDT on a
> CMake-based project which does not come with a .project file, and where the
> project may not allow to check in an IDE project file into their version
> control.
>
> Or should the "Import cmake project" take care of this ?
>
> That’s probably the better way. Though in either case, how do you know what
> the build configurations are? It’s a mistake to not check in the .project
> and other project meta data files. That’s like telling people not to check
> in .vcproj files. We need to understand why projects don’t want to do that
> and address their issues.
do you suggest that projects which are built using cmake additionally check in .project files for Eclipse into their VCS which defines the build types ?
There can be any number of build dirs ( = build configurations ?) for one source dir with cmake projects: debug, release, different compilers, different compiler versions, etc.,
This is up to the user ( = the developer who builds the project), not really defined by the "project" (= the source and build files).
Beside this technical issue, I think there would quite often be resistance to checking in project files for some IDEs in projects which are built using cmake. There should in general be just one source of information, and from there everything should be generated.
> > want CMake to generate Makefiles and CDT calls make on those Makefiles to
> >
> > do the build. The only thing CDT cares about is what the compile commands
> >
> > are so we can use them to generate information so CDT can understand the
> >
> > code.
>
> Ah, ok.
>
> Currently the information in the compile_commands.json file is limited, it
> is really only one compile command for every source file.
>
>
>
> That’s actually all we need for the CDT’s code parsers.
Ok.
> I guess you need to know which targets/executables are built in the project
> ?
>
> We don’t really need that. The CDT searches all build output directories
> looking for binaries.
Who will populate the "make targets" view ?
Where will that information come from ? Isn't this needed before the targets have been built ?
> We can do some fancier things if we do know the
> layout. I assume CMake always generates these things the same, no?
Depends on what you mean exactly. Many things can be tweaked: the names of the executables on disk don't have to be the same as the names of the make-targets, the executables don't have to be in the directory where they are built, but in any other directory
somewhere in the buildtree, etc.
> In the end, we may have to parse the CMakeLists.txt files ourselves and get
> this information.
I recommend not to do this.
Potentially this means CDT would not only have to parse, but also execute at least a subset of the cmake commands: add_executable(), set(), function(), macro(), if(), include(), find_package(), probably more (add_executable() can be wrapped in a function or
macro, the name of the target can be constructed in some way using set(), there may be conditions, etc.).
OTOH if CDT would use information created by cmake in a format which CDT would like to have with exact the information CDT needs, this information would be reliable and correct, no guessing involved, and no reimplemntation of cmake commands (and following their
changes in behaviour over cmake versions) required.
> And which compiler is used, so the correct error parsing can be enabled ?
>
> We can guess that based on the compile command. In the end, there really
> aren’t that many compilers out there.
CMake could tell you in detail, whether it's gcc, or Intel, or MSVC, or whatever. :-)
My wish is that CDT and CMake come to a solution which works without workarounds, hacks, which can be tested in the nightly tests, etc.
I would recommend that somebody joins the cmake-devel list:
https://cmake.org/mailman/listinfo/cmake-developers
and checks out what the other cmake developers recommend.
It could be a generator, or it could be an extension of compile_commands.json, or it could be the fancy thing Stephen Kelly is working on:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658
Alex
