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.
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.
On Thu, Apr 4, 2019 at 2:07 PM Martin Weber <fifteenknots...@gmail.com>
wrote:
> Am Mittwoch, 3. April 2019, 23:52:38 CEST schrieben Sie:
> > On Wed, Apr 3, 2019 at 2:18 PM Martin Weber <fifteenknots...@gmail.com>
> >
> > wrote:
> > > Am Mittwoch, 3. April 2019, 22:26:59 CEST schrieb Benjamin Shadwick:
> > > > I tried cmake4eclipse, and it's a mixed bag. It requires a lot of
> > >
> > > tweaking
> > >
> > > Really? Just set _CMake Builder (portable)_ as the current builder and
> > > build.
> >
> > It required a lot more tweaking than that for an out of source build,
>
> cmake4eclipse enforces out of source build by default, with the build
> directory below project root.
>
> > including manually enabling the CMAKE includes and defines providers.
>
> cmake4eclipse is not a tool to configure your project. Aside from that,
> the
> CDT API does not allow to fully configure a project programatically.
>
> >
> > > > of the Eclipse project after you create it, and I'm pretty sure it
> > >
> > > suffers
> > >
> > > > from the same problem of leaving you with an Eclipse project whose
> > > > source
> > > > tree reflects what is in the filesystem rather than what is defined
> in
> > >
> > > the
> > >
> > > > CMake project.
> > >
> > > What does that mean: _an Eclipse project whose source tree reflects
> what
> > > is in
> > > the filesystem rather than what is defined in the CMake project._ ??
> >
> > This is exactly what I'm getting at: People have marinated so much in the
> > way Eclipse works by default that what I'm saying sounds like a non
> > sequitur.
> >
> > I'll try to explain:
> > - I have a repository with a large source tree that contains hundreds of
> > leaf directories.
> > - Each leaf directory contains source that needs to be built into a
> shared
> > library or an executable binary.
> > - The source tree contains a superset of the functionality that is needed
> > by all configurations.
> > - Any particular configuration of the CMake project will result in only a
> > subset of the libraries and/or binaries being built.
> > - The subset being built is defined via CMake option() commands that set
> > (or don't) cache variables that control which subdirectories are added to
> > the CMake project.
> >
> > What I want from Eclipse:
> > - Only show in the project tree and Open Resource dialog the subset of
> > source files that belong to the current configuration of the CMake
> project,
> > so that developers don't get confused about what is relevant or not to
> the
> > configuration of CMake they are working in.
> > - Only index the subset of source files that belong to the current
> > configuration of the CMake project, so that resources are not wasted
> > indexing irrelevant sources, and so that developers are not flooded with
> > irrelevant indexer errors.
> > - Show header files that are assigned to a target, including custom
> > header-only targets ("custom_target(... SOURCES)"), as is done by other
> > IDEs.
> >
> > > If the IDE indexing all source files takes too long, I would say it is
> a
> > > problem with the IDE; but not a problem of cmake's IDE project
> generator
> > > (as
> > > the topic states).
> >
> > Time is only one aspect (see above), although it's particularly bad with
> > the out-of-box Eclipse project generated by CMake's default settings
> > because it indexes every source file 3 times.
>
> Well, that's CDT. If you press 'Apply and Close' in the project property
> dialog, if write the file 2 times to disk :-[
>
> >
> > > That's the only way to go in your case. How should the CDT4 project
> > > generator
> > > know about all your source files that do not take part in a build?
> >
> > The point I'm trying to make is that I *don't* want Eclipse to know about
> > source files that are *not* being built, but it *does* know about them
> > because all solutions (CMake generator, cmake4eclipse) just point Eclipse
> > at the source tree *in the filesystem*, and not at the conceptual project
> > tree defined via the CMakeLists.txt hierarchy. Remember that for me, the
>
> OK, I see your point. CDT indeed has no concept of 'conceptual project
> tree'
> as you name it.
> But it has filters for files in the source tree! And these seem to operate
> on
> a per-configuration-base.
> And cmake4eclipse already has a parser for the compile_commands.json file
> produces by cmake. That file lists each file in the build.
>
> My idea to ease your problem is to have a menu action in the UI that
> configures the source file filter of the project based on the files listed
> in
> the compile_commands.json file.
> ...
> > - Any particular configuration of the CMake project will result in only a
> > subset of the libraries and/or binaries being built.
> > - The subset being built is defined via CMake option() commands that set
> > (or don't) cache variables that control which subdirectories are added to
> > the CMake project.
>
> You would create a CDT project configuration for one of the particular
> configuration of your CMake project and define the corresponding CMake
> option() values on the cmake4eclipse Symbols tab, build the project to
> create
> the compile_commands.json file. Then run the menu action and let it adjust
> the
> source file filter.
> Of course you would have to repeat the actions above for each of your
> particular configurations.
>
> But my idea would only help iff
> -) compile_commands.json file lists only the source files that take part
> in
> the build.
> -) CDT's indexer indeed respects the filter for source files.
> -) Concerning your point ' Show header files that are assigned to a
> target,
> including custom header-only targets', I'm not sure whether CDT supports
> that.
> Its 'Include Directories' folder view is unmaintained since years.
>
> A final warning:
> My suggestion is based on cmake4eclipse (it is around since 2013), and
> that is
> based on the 'CDT Managed Build System'.
> In 2018, the CDT project lead decided to deprecate 'Managed Build' and to
> replace it with sth. called Core Build. AFAICT, Core Build requires You to
> provide makefiles to build and is focused on GCC/emdedde controllers ATM.
> CDT
> Core Build claims to have additional cmake support but; (I'm biased:) WTF.
> To summarize my warning: If your product lifecycle is at +5 years, lookout
> for
> a different IDE. Or split it into sub-projects with individual releases.
>
> Martin
>
> --
> Cd wrttn wtht vwls s mch trsr.
>
>
>
>
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
