|
Notes |
|
|
(0037435)
|
|
RolandSchulz
|
|
2014-12-10 16:14
|
|
I don't think workspace is the correct mapping either. Ideally it should be possible to have multiple projects in each workspace, and for each project use the build configurations to choose different cmake builds. Thus cmake should originally generate a project with one build configuration, and then one should be able to create another build folder and add that as a build configuration to the original project.
But I'm not sure cmake generating those files is the best approach. It might be easier to solve this problem on the CDT side by reading some of the files generated by CDT and generate the correct build configuration based on that. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=350206, [^] https://github.com/rungemar/cmake4cdt, [^] https://github.com/eblen/Eclipse-CMake-language-settings-provider [^] for some unfinished work towards that end. |
|
|
|
(0037436)
|
|
Gregory Kramida
|
2014-12-10 16:46
(edited on: 2014-12-10 16:47) |
|
Dear Roland,
I'm not sure what you mean by "different cmake builds." Do you mean compiler/linker configurations, such as Debug/Release? These are supported by eclipse CDT, but not by the CDT project type that CMake generates. This is a different problem, and I'd open a separate feature request for that.
I don't see how generating a Workspace for eclipse is an issue. If indeed it is an issue for some reason, that would mean generating a whole Visual Studio solution is an issue, since the two are semantically equivalent (sure, sure, with some squinting of the eyes at differences in features available between the two). I see it a better variant than separate projects within eclipse, as it provides a more natural target/project correspondence.
Ultimately, off course, it would be up to the devs to decide on this, but thank you for weighing in.
|
|
|
|
(0037440)
|
|
RolandSchulz
|
|
2014-12-10 21:27
|
|
Yes Debug/Release would be an example. But build configurations could be more flexible than that. E.g. two different builds could use a different compiler or have a cmake variable set differently. And you are right, that right now, those kind of different build configurations are supported by standard CDT but not by the cmake CDT project type.
I disagree with your assessment that workspace is semantically equivalent to a VS solution. An Eclipse workspace can contain multiple unrelated projects and it is common for people to use it that way. In fact some people always use the same workspace for all of their projects (even though I wouldn't recommend that).
And a CDT project is definitely not equivalent with a VS target. In fact CDT has make targets. I don't remember whether those get populated by the cmake CDT generator. But they do map nicely to the cmake targets. |
|
|
|
(0037441)
|
|
Gregory Kramida
|
2014-12-10 22:12
(edited on: 2014-12-10 22:27) |
|
Well, I've researched some more on the issue, and yes, I agree that workspaces are not entirely equivalent to solutions. One substantial difference is that workspaces contain some individual preference/settings information that is theoretically unrelated to the project (and project set / solution), all of which you wouldn't want to have to re-specify each time you made a new workspace. This could theoretically pose some small problem to the modification I propose.
Zoltán Ujhelyi on stack overflow made this remark and also talked about "project sets" as a possible alternative, so these are up for consideration as well.
Yes, I also am used to having unrelated projects in Eclipse (in various languages too), and I can see how it seems to you like being different, it did to me too at first glance. And yes, I'm aware of Make targets that CDT can handle in makefile projects. I'm not sure why they're not fully utilized by CMake, or am I wrong about this?
I never said targets are equivalent to projects, I just said they facilitate an easy mapping, just like VS projects are mapped to CMake targets.
Indeed, one way to solve this conundrum would be to have CMake automatically (in a single run) generate a target for each permutation of compiler configuration and cmake target. This would result in this kind of list of targets:
library_a_Debug
library_a_Release
library_b_Debug
library_b_Release
exec_a_Debug
exec_a_Release
...
You can see how this gets really messy really quick. And I'm not even adding the common "RelwithDebInfo" and "MinRelInfo", then it would get really ugly. Now, try to build everything for Debug. You have to choose each individual target one at a time. Now rebuild everything for Debug... You get my point.
Now, if we had workspaces with native CDT projects (not makefile projects!) for each target instead, not only does it gain a sense of order, but if you have to build for debug, just choose this as active configuration, and hit Ctrl+B (Build All). Still not great, because you have to change the active configuration for each project, but still, much easier.
Probably, the best way to go about this would be to have both of these as separate generators. I'm sure both ideas will have many supporters.
P.S. apparently, many people agree that Workspaces == Solutions,
That very same SO post here, check the second answer:
https://stackoverflow.com/questions/3796769/how-to-organize-projects-and-solutions-in-eclipse/3797661#3797661 [^]
Check out these other articles:
http://ian-ni-lewis.blogspot.com/2011/05/im-slowly-learning-to-hate-eclipse-less.html [^]
http://www.ibm.com/developerworks/library/os-eclipse-visualstudio/ [^]
http://www.hugoestrada.net/node/121 [^]
|
|
|
|
(0037442)
|
|
RolandSchulz
|
|
2014-12-11 00:19
|
|
I didn't suggest to map compiler configurations to make targets. Different cmake builds (different cmake build folders with Debug/Release or other cmake variables changed) should be mapped to cdt build configurations. cmake targets should be mapped to make targets. I think that's the most natural mapping between cdt and cmake. I have the impression you come from VS and try to transferring the cmake->VS mapping to cdt, instead of thinking of the best natural mapping of directly mapping cmake to cdt.
clion or qt-creator are examples of really good cmake support and I think are much better examples than VS of how to do it well. The VS mapping which causes the source of the same project to be split over multiple projects is really odd to me. It might make sense if your cmake project has multiple targets which are completely independent and thus you want to see the source organized in the IDE in separate projects. But in that case why do you have it organized as a single cmake project and not as separate cmake projects (maybe with a central cmake file building all using ExternalProject). |
|
|
|
(0037443)
|
|
Gregory Kramida
|
2014-12-11 08:16
(edited on: 2014-12-11 08:17) |
|
Roland, let's not jump on assumptions.
No, I don't "come from VS", I'm a linux guy and work mostly in Eclipse. I just prefer to make my projects cross-platform and make sure they work on Windows as well.
Are you saying that for a CDT project ("non-makefile"), you can use multiple targets as well? If so, that might be a good idea too, and I'd be willing to reevaluate my position / re-compare it to the "workspace generation" idea in more detail.
However, I still don't see what's wrong with the workspace generation / multiple project idea. If the Solution/Project mapping seems "unnatural" to some, well, I think that could be simply because they're not used to it (and, frankly, a bit closed-minded about it). What is the actual practical problem you see with it?
Also, turned out that by setting up "referencing" between projects, one can avoid changing active configuration in multiple projects to build all. It's not as straight-forward as solution (global) configruations in VS, but still better than nothing.
|
|
|
|
(0037467)
|
|
Gregory Kramida
|
|
2014-12-16 09:11
|
|
|
Anyone else care to share their opinion on this issue? Perhaps any of the developers? |
|
|
|
(0039396)
|
|
Gregory Kramida
|
|
2015-09-10 09:58
|
|
The proposed feature is also a potential fix for the problem I am experiencing with eclipse indexer getting confused due to duplicate paths in CMake-generated eclipse CDT (Makefile) project. (Mentioned here: http://www.cmake.org/Bug/view.php?id=15725#c39382 [^])
A large project with multiple subprojects generates a source tree, duplicate links to source files under the [Targets], and triplicate links to the same source files under the [Subprojects] virtual folder. CDT's "open declaration" then keeps re-opening the same files multiple times, which causes editing/saving conflicts, GUI cluttering, and general confusion (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=471990 [^] [^]).
If it was possible to switch to generating eclipse Workspaces instead of projects, there can be a single project with a single source tree for each subproject, avoiding the duplicate issue. |
|
|
|
(0040541)
|
|
Alex Neundorf
|
|
2016-02-24 16:31
|
|
|
Generating one workspace containing a project for every subproject (or target ?) would mean that it wouldn't be possible to have buildtrees for different configurations (e.g. a release- and a debug-build) loaded at the same time, right ? |
|
|
|
(0040543)
|
|
Gregory Kramida
|
|
2016-02-24 18:21
|
|
@Alex Neundorf, yes, I think you are right. Good point. In that regard, generating projects as native Eclipse CDT projects instead of Makefile CDT projects looks attractive. That would allow the same project to have multiple build configurations, instead of having to load Debug/Release versions of the same project (with the same sources) as separate CDT projects.
|
|
|
|
(0042686)
|
|
Kitware Robot
|
|
2016-06-10 14:29
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|