<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 3, 2019 at 2:50 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">
To implement the 'index only files referenced through the build script' view, <br>
*any* IDE would have to *interpret* the build scripts. <br>
Just choose an IDE that has a build script interpreter to solve your use case.<br></blockquote><div>Qt Creator and Visual Studio Code (with the appropriate plugins installed) seem to be able to do this. I now use them at home in preference over Eclipse CDT because of this, but Eclipse CDT is currently the path of least resistance at work.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> cmake4eclipse are taking advantage of what modern Eclipse versions can do.<br>
<br>
Sounds promising. What is it that _modern Eclipse versions can do_?<br></blockquote><div><br></div><div>It looks like you can compose the Eclipse project tree to look any way you want via use of linked resources. Apparently when doing this in older versions of Eclipse, it would break its version control integration. This no longer seems to be the case.</div><div><br></div><div>When using the CMake Eclipse project generator via its default settings, I get a "[Targets]" virtual directory in the Eclipse project that actually shows the source files under their respective targets, in a structure that is closer to that defined in the CMake project than what is on the filesystem. Unfortunately it also generates a bunch of *other* garbage to make things work in older Eclipse releases that just create a bunch of noise in new releases that make the project almost unusable for anything but building.<br></div></div></div>