Re: [CMake] Shortcomings with exporting and importing targets
As a followup to my previous email dated 7/15/19, I learned from a co-worker this week that if Project A's target_link_libraries() links against an explicit path+filename of an external library, a subsequent install(TARGETS ...) command will actually include that dependency in the exported target for Library A1, such that it will be picked up as a transitive dependency when later linking Library A1 into a binary in Project B. This makes me think that install(TARGETS ...) not supporting imported targets is likely an oversight by the CMake developers. This ought to be fixed, because it effectively discourages people from following the "modern CMake" approach of using targets wherever possible. -- 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
[CMake] Shortcomings with exporting and importing targets
I'd like to discuss some shortcomings of CMake with regards to sharing targets among projects. Other people have brought this up on this mailing list in the past, but there has never been any useful feedback on it. I'm going to refer to two projects: - "Project A" produces some libraries - "Project B" depends on libraries and headers from Project A First I'll discuss the easier scenario: Project A is built and installed ahead of time, and is therefore already present as a complete installation before Project B is configured. In the case that some of Project A's libraries are produced via ExternalProject_Add() (e.g. due to the lack of a CMake build system, or because they are dependencies of Project A's core code), CMake's install(TARGETS ...) does not support re-exporting shared imported library targets+properties. I've worked around this by writing my own CMake functions that invoke file() to generate CMake modules containing target import and property set commands. I also use file() to generate a CMake package config that loads the target import module. I was careful to base everything on CMAKE_CURRENT_LIST_DIR, so that the installation is portable. This solution works great: Project B is able to do a find_package(ProjectA CONFIG) to get all the targets+properties for the libraries and headers in the Project A install, reducing Project B's build system dependence on Project A to a few target_link_libraries() commands referencing the imported targets. I don't even need to explicitly mention the Project A header directories anywhere in Project B, because CMake takes care of it via target properties. Of course, this is still non-optimal because I now have a wacky target re-export function to maintain in Project A. It would be better if CMake would just handle things for me via install(TARGETS ...) or similar. Now comes the more difficult case: I want to create a super-build Project X that builds both Project A and Project B. My first instinct is to use ExternalProject_Add() to build Project A, because developers of Project X and/or B don't care about its source code - they only care about the headers and libraries. Unfortunately this is a complete non-starter, because ExternalProject_Add() doesn't invoke any part of Project A's build system until the *build* step of Project X, which means that we'll never get the package config stuff in time for Project B's configure step. OK, so let's resign ourselves to the fact that we have to use add_subdirectory() to build Project A, polluting Project X both with Project A's source and its CMake cache variables. This is *still* not going to work (yet), because CMake bafflingly *only* flows first-class (add_library()/add_executable()) targets upwards from Project A to Project X & B and does *not* flow import targets upwards! I'm not sure this is documented anywhere, but I have convinced myself that it is absolutely the case in CMake 3.12.2. So we can't use the Project A's native import targets even though we're doing add_subdirectory() in Project X. What can we do? My approach was to modify Project A as follows: 1. Extend my import target + package config functions to support writing either build tree or install flavored modules. 2. Generate the install flavored modules with an "INSTALL-" prefix on their filenames, and have install() rename them on install. 3. Generate build flavored modules in the build tree during the CMake configure step. I then modified Project X to add the build directory to CMAKE_PREFIX_PATH, and Project B was able to load Package A's modules via find_package(ProjectA CONFIG). This almost got everything working, but there was one final bump: Parallel building fails with an error that Project B cannot find Project A's libraries! This is because Project B is now using a separate set of import targets defined by modules produced by Project A, which do not tie back to the *actual* targets being used to build Project A! Oof. Fortunately, it turns out that ExternalProject_Add() targets *do* flow upwards to Project X and back down to Project B, even though the imported library targets do not. This means I was able to modify Project A's target import module generator function to include add_dependencies() commands - in the build-flavored module only! - that tie the targets imported by Project B to the ExternalProject_Add() targets in Project A. This also means that Project B can use a pre-build+installed Project A without any changes to the former's build system. Now take a step back and look at how much text I just wrote, all because CMake has the following limitations that I had to overcome: 1. install() does not support re-exporting imported library targets+properties. 2. ExternalProject_Add() doesn't do anything until the build step (NOTE: I understand why this is the case, and also that there are ugly workarounds). 3. Sub-projects pulled in via add_subdirectory() do not flow imported library
[CMake] CMake install doesn't find binary that CMake built?
Using CMake 3.12.2.
Consider the following project:
project(myproject)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
set(CMAKE_INSTALL_PREFIX "${CMAKE_BINARY_DIR}" CACHE PATH "" FORCE)
add_executable(myprog hello.cpp)
install(TARGETS myprog
ARCHIVE DESTINATION lib
LIBRARY DESTINATION lib
RUNTIME DESTINATION bin)
'make install' builds 'myprog', then it disappears, then CMake reports an
error that it cannot find it ("file INSTALL cannot find
"path_to_build_directory/bin/myprog"").
Seems like a bug/oversight. Possibly CMake is trying to move the file to
where it already exists, destroying it in the process.
And since someone will be horrified at what I'm doing with paths, the
reason is that I've got subprojects that generate hundreds of libraries and
multiple executables, and I'd like to avoid both of the following:
- Forcing developers to run 'make install' instead of 'make' before they
can run
- Setting up massive PATH and LD_LIBRARY_PATH variables so that everything
can be found when it's scattered all over the build tree
I suppose my current setup will work fine as long as nobody uses 'make
install', but I was hoping to leverage that to help with release packaging.
--
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
Re: [CMake] Ubuntu CMake Repository Now Available
I believe it's possible to specify an "or" rule so that it would work with either package. It should probably require the one it's built against though, or at least prefer it if it works with both. On Tue, Apr 9, 2019 at 12:32 PM Hahn, Steven E. via CMake wrote: > Would you consider updating the Ubuntu 18.04 package to depend on libcurl4? > > Unfortunately libcurl3 conflicts with libcurl4, and I need to keep the > later installed for packages that depend on it. The Ubuntu-provided CMake > package appears to be built against libcurl4. > > Steven > > On 4/5/19, 3:17 PM, "CMake on behalf of Kyle Edwards via CMake" < > cmake-boun...@cmake.org on behalf of cmake@cmake.org> wrote: > > All, > > I am pleased to announce that Kitware is now offering an > officially-supported set of Ubuntu packages for CMake. These CMake > packages can be installed with apt-get, just like other Ubuntu > packages. We currently support Ubuntu 16.04 and 18.04. > > The following packages are available: > > * cmake - Contains the CMake command line executable, CTest, and CPack. > * cmake-curses-gui - Contains ccmake. > * cmake-qt-gui - Contains cmake-gui. > * cmake-doc - Contains the CMake documentation. > > To use these packages, follow the instructions at > > https://apt.kitware.com/ > > to add our APT repository to your Ubuntu installation, and then use > apt-get install to install one or all of the above packages. > > We currently offer CMake 3.14.1, and will continue to update the > repository as new CMake releases are issued. > > Kyle > -- > > 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 > > > -- > > 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 > -- 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
Re: [CMake] Eclipse generator question
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
wrote:
> Am Mittwoch, 3. April 2019, 23:52:38 CEST schrieben Sie:
> > On Wed, Apr 3, 2019 at 2:18 PM Martin Weber
> >
> > 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
Re: [CMake] Eclipse generator question
On Wed, Apr 3, 2019 at 2:50 PM Martin Weber wrote: > To implement the 'index only files referenced through the build script' > view, > *any* IDE would have to *interpret* the build scripts. > Just choose an IDE that has a build script interpreter to solve your use > case. > 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. > > cmake4eclipse are taking advantage of what modern Eclipse versions can > do. > > Sounds promising. What is it that _modern Eclipse versions can do_? > 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. 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. -- 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
[CMake] Fwd: Eclipse generator question
Oops, meant to send this to the mailing list, but GMail keeps trying to
divert me.
-- Forwarded message -
From: Benjamin Shadwick
Date: Wed, Apr 3, 2019 at 2:52 PM
Subject: Re: [CMake] Eclipse generator question
To: Martin Weber
On Wed, Apr 3, 2019 at 2:18 PM Martin Weber
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,
including manually enabling the CMAKE includes and defines providers.
> > 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.
> 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
filesystem contains lots of sources that are *not* relevant to any one
CMake configuration that developers will be working with.
--
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
Re: [CMake] Eclipse generator question
FYI, I opened a bug on CMake's tracker about updating the CMake generator since its outputs are kind of garbage for modern CDT releases: https://gitlab.kitware.com/cmake/cmake/issues/19107 Unfortunately the only feedback I got was that there is a push to remove *all* generators in favor of forcing IDEs to use cmake-file-api. I opened a bug on the Eclipse tracker asking if they knew about this push and whether anyone was working on it from the CDT end, and they aren't but are receptive: https://bugs.eclipse.org/bugs/show_bug.cgi?id=545905 None of that helps me, though, because I'm stuck on CMake 2.8.12.2 for now. I think my main philosophical issue is that CMake lets you define a project, and I'd like to see that definition reflected in Eclipse. Unfortunately, both the CMake Eclipse generator and cmake4eclipse plugin leave you with a filesystem-oriented view of the source instead of a CMake project oriented view. You can get most of this from importing a CMake project into something more primitive like NetBeans. Maybe being tied to the filesystem view is an inherent limitation of Eclipse (and/or CDT), or maybe it was at one time and neither CMake nor cmake4eclipse are taking advantage of what modern Eclipse versions can do. On Wed, Apr 3, 2019 at 1:32 PM Martin Weber wrote: > Am Mittwoch, 3. April 2019, 18:44:04 CEST schrieb Benjamin Shadwick: > > Update - I think I found a tolerable workaround: > > > > If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and > > then inject a link to my include directory into the .project file, things > > work a lot better: > > You (and other having problems with eclipse projects generated by cmake) > might > want to read these posts of the CDT project lead concerning cmake's CDT4 > generator [1] [2]. > > Martin > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=530090#c3 > [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=530090#c5 > > > -- > 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 > -- 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
Re: [CMake] Eclipse generator question
I tried cmake4eclipse, and it's a mixed bag. It requires a lot of tweaking 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. It's really annoying that I spent all this time building a CMake project for a complex codebase, only to have the IDE present and index the entire source tree on the filesystem instead of the subset that is actually being built by the CMake configuration. I should probably enhance my project-tweaking python script to add filters to the generated Eclipse project to hide anything that isn't in the CMake project. On Wed, Apr 3, 2019 at 1:02 PM Martin Weber wrote: > Am Mittwoch, 3. April 2019, 18:44:04 CEST schrieb Benjamin Shadwick: > > Update - I think I found a tolerable workaround: > > > > If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and > > then inject a link to my include directory into the .project file, things > > work a lot better: > > - I get only one copy of each source file in the Open Resource dialog. > > - I get source and header files in the Open Resource dialog. > > - I can toggle between source and header. > > - I can build from Eclipse. > > - I get version control support, even in my include tree. > > - Indexing is fast. > > > > It seems that Eclipse improved version control support quite a bit since > > the CMake Eclipse generator was last touched. Unfortunately this seems to > > also mean that a lot of the linked resources that CMake generates by > > default now just add noise (hence my better results from turning them > off). > > Newer versions of CDT (9.1+) seem to have trouble to properly read the > .cproject file generated by cmake [1] [2]. > > Forget about running cmake manually and install _cmake4eclipse_ from the > eclipse marketplace. It runs cmake automatically [3] and comes with > support > for the eclipse indexer. Some people even use it for CUDA in the nvidia > insight IDE. (Disclaimer: I am the maintainer) > Just try it with one of the example projects [4]. > > Martin > > [1] <https://cmake.org/pipermail/cmake-developers/2019-March/031125.html> > [2] <https://www.eclipse.org/forums/index.php? > t=msg=1094239=1797891
Re: [CMake] Eclipse generator question
Update - I think I found a tolerable workaround: If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and then inject a link to my include directory into the .project file, things work a lot better: - I get only one copy of each source file in the Open Resource dialog. - I get source and header files in the Open Resource dialog. - I can toggle between source and header. - I can build from Eclipse. - I get version control support, even in my include tree. - Indexing is fast. It seems that Eclipse improved version control support quite a bit since the CMake Eclipse generator was last touched. Unfortunately this seems to also mean that a lot of the linked resources that CMake generates by default now just add noise (hence my better results from turning them off). There are still some aspects that are not ideal. In particular, CMake brings the source files into the project via the "[Source directory]" virtual folder, which just points to the CMake project root directory on the filesystem. This approach has a number of issues: - Source files that are not part of the CMake project show up in Open Resource and possibly the Eclipse CDT index. - A view of the sources/headers belonging to each CMake target is not really provided (although you can glean the sources part somewhat by looking at the detailed target tree). On Tue, Apr 2, 2019 at 9:04 AM Benjamin Shadwick wrote: > I've recently converted a complex C++ codebase to CMake. I'm stuck using > 2.8.12.2. > > The codebase has a source tree, whose leaf directories each build a shared > library or an executable binary. The source lives in src/ while the headers > live in a separate tree under a sibling include/ directory. > > Based on advice from the Internet, I am trying to do out-of-source builds, > with the debug flavor in a debug/ sibling directory, and release in release/ > > This all works from the command line, but I am using Eclipse CDT as my > primary IDE and would like to get decent integration between that and CMake. > > When I use CMake's Eclipse generator and then import the project into > Eclipse, there are some serious issues. The primary issue is that when I > hit Ctrl+Shift+R to bring up the Open Resource dialog and then type in the > name of a source file, I get 3 results: one under each of [Source files], > [Subprojects], and [Targets]. This is awful, especially since picking the > wrong one results in weird behavior like inability to resolve include > directives or inability to toggle between source and corresponding header > file. > > Is there some way to address this without resulting to in-source builds? > I'm even willing to butcher the project files post-generate using Python if > it would help. > > Thanks, > - Ben S. > -- 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
[CMake] Eclipse generator question
I've recently converted a complex C++ codebase to CMake. I'm stuck using 2.8.12.2. The codebase has a source tree, whose leaf directories each build a shared library or an executable binary. The source lives in src/ while the headers live in a separate tree under a sibling include/ directory. Based on advice from the Internet, I am trying to do out-of-source builds, with the debug flavor in a debug/ sibling directory, and release in release/ This all works from the command line, but I am using Eclipse CDT as my primary IDE and would like to get decent integration between that and CMake. When I use CMake's Eclipse generator and then import the project into Eclipse, there are some serious issues. The primary issue is that when I hit Ctrl+Shift+R to bring up the Open Resource dialog and then type in the name of a source file, I get 3 results: one under each of [Source files], [Subprojects], and [Targets]. This is awful, especially since picking the wrong one results in weird behavior like inability to resolve include directives or inability to toggle between source and corresponding header file. Is there some way to address this without resulting to in-source builds? I'm even willing to butcher the project files post-generate using Python if it would help. Thanks, - Ben S. -- 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
