Home » Language IDEs » C / C++ IDE (CDT) » Best method for auto-configuring build settings
| Best method for auto-configuring build settings [message #1732991] |
Mon, 23 May 2016 14:49  |
 Tamás Kiss
Messages: 11
Registered: May 2016 |
Junior Member |
|
|
Hi,
I'd like to ask for help to decide what would be the easiest option to easily set up the build settings for an imported Makefile project.
We have a repository, with many projects in it, and storing the Eclipse project config files there is not an option (seriously, it's out of question). So, importing a Makefile project to Eclipse involves the following steps, if we want to be able to benefit from its "semantic" features:
- Set a build environment variable (needed in the next step).
- Modify the command in the CDT GCC Built-in Compiler Settings Provider to use a custom gcc variant, which also uses the exported environment variable we set previously.
- Add the custom include paths and preprocessor macro definitions to the CDT Managed Build Setting Entries Provider (or to the CDT User Setting Entries, though I never used the latter). This step is very time consuming and error prone, it involves looking into the large, non-trivial Makefile, and do several dozens of mouse clicking (my hands usually hurt by the time I finish).
- Disable all the other providers except the above two, to prevent interference with our settings.
- Rebuild the Index.
- Enjoy - that is, until a Git operation trashes the project configuration.
The trick is that the environment variable, the preprocessor command, and all the include paths and macro definitions for a given project are all depend on which commit is checked out. On the other hand, all info can be programmatically extracted from the Makefile eg. by writing an "introspection" make target to display the settings. This is what made me thinking, that an Eclipse plugin could deal with the settings, parsing this theoretical make target output. (I know that there's a CDT GCC Build Output Parser, but it's not always reliable, and also we sometimes don't have the opportunity to build the project in Eclipse.)
My problem is that I can't figure out the best way to do it. E.g. probably a custom Language Settings Provider could provide the custom include dirs and macro defs based on the Makefile "introspection" target output, but what about reconfiguring the other providers, and to adding environment variables, etc?
Another solution would be to add a custom "action" to the project somehow (e.g. a menu item in the project's context menu, like the "Run C/C++ Code Analysis"), which would update the configuration each time the user selects it.
Do you have any suggestions, how this functionality could be best implemented?
Thanks,
Tamas
|
|
|
| Re: Best method for auto-configuring build settings [message #1733149 is a reply to message #1732991] |
Tue, 24 May 2016 12:14  |
David Vavra
Messages: 1426
Registered: October 2012 |
Senior Member |
|
|
If you already have a makefile why don't you use it? The Eclipse build settings are to generate makefiles and Managed Builds are a substitute for Make..
The only thing you would need to setup would be telling the Indexer where your header files are. Are they really that complicated?
You can save these someplace that git can't, er, git to. Ready to re-import into Eclipse if needed. And save your new project there, too.
For that matter, you could make an empty project with some of the settings already made and use that as your starter for the next.
Why can't you save the project and (I guess, cproject) files. They are just text.
[Updated on: Tue, 24 May 2016 19:19] Report message to a moderator |
|
|
| Re: Best method for auto-configuring build settings [message #1733165 is a reply to message #1733149] |
Tue, 24 May 2016 21:30 |
Tamás Kiss
Messages: 11
Registered: May 2016 |
Junior Member |
|
|
You are right, I need the settings only to configure the indexer. Without them, the indexer is totally clueless, and this means that none of the "semantic" features of Eclipse and CDT work, so there would be no benefit compared to a simple text editor.
I admit I forgot to mention a very important detail: the complication lies in the scale of the problem - imagine this project importing procedure with cca. 150 developers, and 100+ projects in the repo, each project having its own Makefile, and the project dependencies changing depending the checked out commit. Saving and restoring the project files manually can work for an individual designer, if (s)he knows Eclipse and CDT well enough to know what to save, but most of the developers don't know Eclipse, and don't use it often. This also implies that that it's not feasible to exchange such project files among developers, because they don't have the knowledge to verify if any of their settings contain user-specific info (e.g. user-specific paths), or the projects settings are compatible with their Eclipse version and/or plugin versions, and for which commits are those project files applicable.
I also tried to create the projects outside the repo, and then used the linked resources feature to bind the source directory into a project. This worked, but it was very hard to make the build from Eclipse work because the project root is merely an empty directory in this setup, and this confused Eclipse when tried to execute the make command. It was also hard to have Eclipse locate the build error positions in the source files, because the actual build took place in a totally different location in the filesystem than Eclipse expected. And what's more, the Git integration also does not work if the project is not in the repo, even if the sources are all in there. I had to switch to the Git Perspective each time I needed to do a Git operation.
So this is why I thought that auto-configuring the projects based on the data that is implicitly already present in the Makefiles could be beneficial. Imagine that you could import any of the projects, then click on it, select "Update project configuration based on Makefile", and that's it. And after checking out a different commit, update the already existing project the same way.
|
|
|
Goto Forum:
Current Time: Mon Sep 23 13:17:26 GMT 2024
Powered by FUDForum. Page generated in 0.04006 seconds |
] 
Search
Help
Register
Login
Home
