<div dir="ltr"><div>Ah, it seems my CMake is too old to produce compile_commands.json. Maybe this is part of why other IDEs are working better at home on Ubuntu MATE LTS.<br></div><div><br></div><div>Unfortunately Red Hat ships CMake 2.8.12.2 even in recent RHEL releases, which is now approaching 5 years old (yikes!). Apparently they ship CMake 3.13.4 as a 'cmake3' package and I didn't catch it - will see if I can upgrade at least some of my machines.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 4, 2019 at 2:07 PM Martin Weber <<a href="mailto:fifteenknots505@gmail.com">fifteenknots505@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am Mittwoch, 3. April 2019, 23:52:38 CEST schrieben Sie:<br>
> On Wed, Apr 3, 2019 at 2:18 PM Martin Weber <<a href="mailto:fifteenknots505@gmail.com" target="_blank">fifteenknots505@gmail.com</a>><br>
> <br>
> wrote:<br>
> > Am Mittwoch, 3. April 2019, 22:26:59 CEST schrieb Benjamin Shadwick:<br>
> > > I tried cmake4eclipse, and it's a mixed bag. It requires a lot of<br>
> > <br>
> > tweaking<br>
> > <br>
> > Really? Just set _CMake Builder (portable)_ as the current builder and<br>
> > build.<br>
> <br>
> It required a lot more tweaking than that for an out of source build,<br>
<br>
cmake4eclipse enforces out of source build by default, with the build <br>
directory below project root.<br>
<br>
> including manually enabling the CMAKE includes and defines providers.<br>
<br>
cmake4eclipse is not a tool to configure your project. Aside from that, the <br>
CDT API does not allow to fully configure a project programatically.<br>
<br>
> <br>
> > > of the Eclipse project after you create it, and I'm pretty sure it<br>
> > <br>
> > suffers<br>
> > <br>
> > > from the same problem of leaving you with an Eclipse project whose<br>
> > > source<br>
> > > tree reflects what is in the filesystem rather than what is defined in<br>
> > <br>
> > the<br>
> > <br>
> > > CMake project.<br>
> > <br>
> > What does that mean: _an Eclipse project whose source tree reflects what<br>
> > is in<br>
> > the filesystem rather than what is defined in the CMake project._ ??<br>
> <br>
> This is exactly what I'm getting at: People have marinated so much in the<br>
> way Eclipse works by default that what I'm saying sounds like a non<br>
> sequitur.<br>
> <br>
> I'll try to explain:<br>
> - I have a repository with a large source tree that contains hundreds of<br>
> leaf directories.<br>
> - Each leaf directory contains source that needs to be built into a shared<br>
> library or an executable binary.<br>
> - The source tree contains a superset of the functionality that is needed<br>
> by all configurations.<br>
> - Any particular configuration of the CMake project will result in only a<br>
> subset of the libraries and/or binaries being built.<br>
> - The subset being built is defined via CMake option() commands that set<br>
> (or don't) cache variables that control which subdirectories are added to<br>
> the CMake project.<br>
> <br>
> What I want from Eclipse:<br>
> - Only show in the project tree and Open Resource dialog the subset of<br>
> source files that belong to the current configuration of the CMake project,<br>
> so that developers don't get confused about what is relevant or not to the<br>
> configuration of CMake they are working in.<br>
> - Only index the subset of source files that belong to the current<br>
> configuration of the CMake project, so that resources are not wasted<br>
> indexing irrelevant sources, and so that developers are not flooded with<br>
> irrelevant indexer errors.<br>
> - Show header files that are assigned to a target, including custom<br>
> header-only targets ("custom_target(... SOURCES)"), as is done by other<br>
> IDEs.<br>
> <br>
> > If the IDE indexing all source files takes too long, I would say it is a<br>
> > problem with the IDE; but not a problem of cmake's IDE project generator<br>
> > (as<br>
> > the topic states).<br>
> <br>
> Time is only one aspect (see above), although it's particularly bad with<br>
> the out-of-box Eclipse project generated by CMake's default settings<br>
> because it indexes every source file 3 times.<br>
<br>
Well, that's CDT. If you press 'Apply and Close' in the project property <br>
dialog, if write the file 2 times to disk :-[<br>
<br>
> <br>
> > That's the only way to go in your case. How should the CDT4 project<br>
> > generator<br>
> > know about all your source files that do not take part in a build?<br>
> <br>
> The point I'm trying to make is that I *don't* want Eclipse to know about<br>
> source files that are *not* being built, but it *does* know about them<br>
> because all solutions (CMake generator, cmake4eclipse) just point Eclipse<br>
> at the source tree *in the filesystem*, and not at the conceptual project<br>
> tree defined via the CMakeLists.txt hierarchy. Remember that for me, the<br>
<br>
OK, I see your point. CDT indeed has no concept of 'conceptual project tree' <br>
as you name it. <br>
But it has filters for files in the source tree! And these seem to operate on <br>
a per-configuration-base.<br>
And cmake4eclipse already has a parser for the compile_commands.json file <br>
produces by cmake. That file lists each file in the build.<br>
<br>
My idea to ease your problem is to have a menu action in the UI that <br>
configures the source file filter of the project based on the files listed in <br>
the compile_commands.json file.<br>
...<br>
> - Any particular configuration of the CMake project will result in only a<br>
> subset of the libraries and/or binaries being built.<br>
> - The subset being built is defined via CMake option() commands that set<br>
> (or don't) cache variables that control which subdirectories are added to<br>
> the CMake project.<br>
<br>
You would create a CDT project configuration for one of the particular <br>
configuration of your CMake project and define the corresponding CMake <br>
option() values on the cmake4eclipse Symbols tab, build the project to create <br>
the compile_commands.json file. Then run the menu action and let it adjust the <br>
source file filter.<br>
Of course you would have to repeat the actions above for each of your <br>
particular configurations.<br>
<br>
But my idea would only help iff<br>
-) compile_commands.json file lists only the source files that take part in <br>
the build.<br>
-) CDT's indexer indeed respects the filter for source files.<br>
-) Concerning your point ' Show header files that are assigned to a target, <br>
including custom header-only targets', I'm not sure whether CDT supports that. <br>
Its 'Include Directories' folder view is unmaintained since years.<br>
<br>
A final warning: <br>
My suggestion is based on cmake4eclipse (it is around since 2013), and that is <br>
based on the 'CDT Managed Build System'. <br>
In 2018, the CDT project lead decided to deprecate 'Managed Build' and to <br>
replace it with sth. called Core Build. AFAICT, Core Build requires You to <br>
provide makefiles to build and is focused on GCC/emdedde controllers ATM. CDT <br>
Core Build claims to have additional cmake support but; (I'm biased:) WTF.<br>
To summarize my warning: If your product lifecycle is at +5 years, lookout for <br>
a different IDE. Or split it into sub-projects with individual releases.<br>
<br>
Martin<br>
<br>
-- <br>
Cd wrttn wtht vwls s mch trsr.<br>
<br>
<br>
<br>
<br>
</blockquote></div>