Home » Language IDEs » C / C++ IDE (CDT) » Make it Stop Building Dependencies(Eclipse builds dependencies of a project even when I don't want it to)
| Make it Stop Building Dependencies [message #1705903] |
Wed, 19 August 2015 22:31  |
 Nir Friedman
Messages: 5
Registered: May 2015 |
Junior Member |
|
|
I'm using an external build tool, that's handled entirely outside of Eclipse. I have a bunch of different projects in my workspace, which have dependencies between them both in reality, and in Eclipse. These dependencies (expressed in the project references) are necessary so that indexing works properly.
I have played around with different ways of launching the external build tool. I've found that the best way is to, under Project Properties -> Builders, leave CDT Builder checked, and under C++ build, simply enter the appropriate build command. The alternative is to uncheck CDT Builder, and add a new Builder, which is just an external tool. As far as I can tell, this has a very major disadvantage. Assuming your external tool still streams compiler (and unit test) error messages back to stdout and stderr, CDT Builder will parse the output. This gives you two things: hyper links; i.e. you can click on the error messages in the console output and it will bring you to the file, and it will also mark the errors on the left in your file. These two features are invaluable for quick reaching a file and systematically debugging it.
So imagine I am working on a project A, in the workspace, that references project B in the workspace. I create a custom build command in project A, and I rebind Ctrl+B to only build the current project. However, every time I launch the build command for project A, Eclipse also tries to build project B. This is not necessary, as the external build system I use already does everything automatically. Is there any way I can make Eclipse not build dependent projects? I'd prefer a solution more elegant than making every build except for the one I'm working on a no-op at any given time.
|
|
| | | |
| Re: Make it Stop Building Dependencies [message #1705974 is a reply to message #1705972] |
Thu, 20 August 2015 15:13  |
Nir Friedman
Messages: 5
Registered: May 2015 |
Junior Member |
|
|
If I understand you correctly, it seems like you manually enter all the include paths that any given project needs. This means that if project A uses project B, and the underlying build system has several include paths for project B, that means I will need to add multiple include paths to project A, just for project B. The number of include paths I'll have to carefully add in this fashion is actually quadratic with the number of projects. Adding a new project goes from quickly ticking off a bunch of boxes, to painstakingly entering a dozen or more paths. Additionally, any time that a slight change in include structure is done, everything will break, so this approach is very brittle as well. I'm not 100% sure what you mean by automatic discovery, but in my approach, all the inter-project includes are discovered automatically via "Heuristic Resolution of Includes"; this normally works within the same project but when you add project references it works across projects as well. This doesn't require Eclipse to parse the output of my build system or anything like that.
I think this approach is strictly more work and less robust than using project references and giving each project a default config build command to just do nothing. Thank you though for sharing, it's always interesting to see how many approaches there are with Eclipse.
|
|
| |
| Re: Make it Stop Building Dependencies [message #1705989 is a reply to message #1705976] |
Thu, 20 August 2015 18:06 |
Nir Friedman
Messages: 5
Registered: May 2015 |
Junior Member |
|
|
The fact that A references B isn't likely to change, but new projects are added not infrequently, there are many different people working on many different subsets of projects. This adds a tremendous amount of work and complexity to project files.
Yes, it has an unwanted side effect. This is because Eclipse's builder is really designed for Makefiles, and it's assumed that projects are separate makes. The idea that the build system is already aware of all the different projects and handles all this automatically is not really how Eclipse sees the world. I'd hardly call my approach the easy way; that's the design. I'm pretty sure project references aren't there for decoration. At any rate, an unwanted side effect is quite orthogonal to robustness. I've already listed reasons why I think my approach is more robust than explicitly listing every include directory.
Heuristic resolution of includes means that within projects, it will try to resolve #includes by looking at where there can possibly be a match. It will simply assume that your build has the appropriate -I arguments. This means both marking the include resolved, and allowing the index for that file to use symbols from the include. I know this is the case, because all my code resolves includes perfectly, and I have not either: a) specified any of the include paths explicitly, or b) allowed Eclipse to parse the build/link commands produced by my build system (which is what I think is called discovery). So there is no other way in which Eclipse could be resolving the includes.
Anyhow, as an update to the problem: one thing that has surprised me (and annoyed me) is the following. I create a "Default" profile for every single project consisting of a no-op build, and I give project A an additional profile "TargetA" with a command, which only depends on other projects "Default" (in project references), and I similarly give project B an additional target "TargetB". I set TargetA and TargetB active. When I build project A, it still insists on running the command specified by TargetB. I would argue that this is simply an outright bug; I explicitly selected that the "TargetA" configuration only depends on the "Default" configuration of project B, so why would it build TargetB?
|
|
|
| Re: Make it Stop Building Dependencies [message #1706204 is a reply to message #1705989] |
Mon, 24 August 2015 18:49 |
David Vavra
Messages: 1426
Registered: October 2012 |
Senior Member |
|
|
Quote: Heuristic resolution of includes means that within projects, it will try to resolve #includes by looking at where there can possibly be a match.
FYI: from the help under Indexer preferences (C/C++):
Allow heuristic resolution of includes
Activate this checkbox to allow the indexer to skip indexing duplicate include files.
It may act as you have said but the documentation implies only a very simple heuristic which is employed to determine when a file might be scanned. You may be confusing it with Use heuristics to resolve paths in the Build Output Parser Options of the Discovery tab.
Quote:Yes, it has an unwanted side effect. This is because Eclipse's builder is really designed for Makefiles, and it's assumed that projects are separate makes. The idea that the build system is already aware of all the different projects and handles all this automatically is not really how Eclipse sees the world.
If you think the spurious builds occurring when using your approach are inappropriate submit a bug report if you haven't already. However you may be merely disagreeing with a design decision and what you really want is an enhancement.
I'm curious though why whatever is actually doing your builds doesn't recognize it has nothing to do and act as a no-op when executed? If it does then it's no different than using make recursively. If you are getting actual builds vs. just messages saying the builder was called, perhaps that is where your problem actually resides?
[Updated on: Mon, 24 August 2015 22:26] Report message to a moderator |
|
|
Goto Forum:
Current Time: Tue Apr 23 05:32:48 GMT 2024
Powered by FUDForum. Page generated in 0.03400 seconds |
] 
Search
Help
Register
Login
Home
