I have a legacy, in-house tool that creates an Eclipse CDT project out of all the C files that I use to run Simulink simulations. I use the eclipse project as front end to GDB (in Windows using Cygwin) to debug by simulation C code. The tool uses an unchanging .cproject file to make the projects.
I am now running my simulations on Unix so I'm trying to port the tool to create an Eclipse project in Unix. I am stuck on how to turn my Windows .cproject file into a Unix .cproject file. For example in Unix Eclipse project build is giving me errors like below:
Managed Build system manifest file error: Option cdt.managedbuild.option.gnu.cross.path.2110017774
uses a null category that is invalid in its context. The option was ignored.
I am guessing that this is being caused by the .cproject file since it is the only file in the tool that has cdt.managedbuild in it.
<option id="cdt.managedbuild.option.gnu.cross.path.2110017774"
superClass="cdt.managedbuild.option.gnu.cross.path" value="MinGWPath" valueType="string"/>
I don't even understand what this file is doing or how it was generated in the first place. I did not create the tool and I am an Eclipse novice. Are there any resources that I could use to understand how to create, modify, and interpret a .cproject file?
.cproject files aren't really designed to be generated by external tools. Their exact format is not documented, and is considered to be an implementation detail.
Extensibility and automation in the Eclipse ecosystem is intended to happen through Eclipse plugins. Eclipse plugins have access to a set of stable, documented APIs which can be used to manipulate an Eclipse workspace. For example, for creating a project you might use APIs like IWorkspaceRoot.getProject(), IProject.create(), and CoreModel.create(IProject). The implementation of these APIs will take care of details such as creating the .cproject file.
If you really want to generate the .cproject file yourself, your best bet is to refer to the CDT source code for details about its exact format, and ask any clarifying questions on the CDT mailing list. It may also be helpful to look at the source code of other cross-platform tools that create .cproject files, such as CMake which has an Eclipse project generator.
Related
I am "quasi-generating" an eclipse project -
I have:
(a) numerous projects I need to create
(b) Every project has the same pattern of source dirs and include dirs
(c) And linker scripts etc...
So I have a small python script that reads a json file with specifics and outputs a .project and .cproject file
This works, but from time to time something goes wrong and I get the "This is not a CDT Project" message in eclipse.
Its very labour intensive to figure out the stupid mistake - my question is this: Is there a way to get eclipse/CDT to tell me what it is choking on? For example a log file of some sort?
Please do not even suggest CMAKE - CMAKE does NOT work for embedded cross-compiling platforms with highly customized Eclipse packages from companies like Xilinx and Microsemi. And the project needs to a CDT project, not a CDT-Makefile project for numerous other reasons. (Which for brevity I will not go into here)
Is it possible to create Eclipse project using make?
I have a bunch of Eclipse CDT c++ projects, but I can't keep the .project and .cproject files in the source reposotory - instead, one option is to create a makefile to be able to re-create Eclipse projects by running make. Would that be possible?
CMake can generate Eclipse project files, you could use that. I haven't come across a way to do it using plain make.
That said, please keep in mind the caveats I mention in this answer about Eclipse project file formats being undocumented and without guarantees of stability.
I have built an Xtext based editor for our DSL which works fine, but we get an out of memory error while the workspace is building or when we force a project cleaning. Our DSL plug-in is used in conjunction with the Eclipse CDT to build microcontrollers test programs. A test program project is made of C++ files and ".xxx" files for which I have built the DSL editor. The out of memory error occurs when the test program project contains at least one large ".xxx" file (~300 Mbyte). We don't even open this large file, we simply clean the project and the memory error occurs.
This seems to be an Xtext indexer issue. Is there a way to tell the Xtext indexer to ignore ".xxx" files located in a particular folder of the project? I have read several times the Scoping chapter of the excellent "Implementing DSLs with Xtext and Xtend" from Lorenzo Bettini, but did not find any solution to this issue. Can you help me, please?
the extension points for this are org.eclipse.xtext.resource.IResourceServiceProvider.canHandle(URI) or org.eclipse.xtext.ui.resource.IResourceUIServiceProvider.canHandle(URI, IStorage)
I'm trying to import a C project to eclipse (CDT) that is managed by waf. There is a list of predefines generated by waf (when running ./waf configure). That list has to be imported to Project->Properties->C/C++ General/Paths and Symbols/Symbols/GNU C so that the indexer knows about them and does not print errors. That list (when using the GUI) is stored to the .cproject file. I created a Build Target that runs ./waf configure and stores the list to a file named DEFINES.txt. How do I automatically update the list of .cproject with the values of DEFINES.txt after running the Build Target?
I thought about the following solutions and their follow-up problems:
Solution: Writing a plug-in.
Problem: What is the appropriate extension point?
Solution: Writing an external program that calls ./waf configure reads DEFINES.txt and writes the list to .cproject. That program replaces the old Build Target.
Problem: How safe is this? Am I allowed to change the .cproject file by an external program without causing any problems?
Solution: Implementing the .cproject updating algorithm in wscript file.
Problem: This is not a solution for me, because the project is used by others, too, that do not use eclipse as IDE. So the modified wscript will cause errors if the other developers want to build the project.
Does anybody have better ideas or some advice?
Here is how to go about it:
Writing a plug-in: What I recommend you do is write an extension to the LanguageSettingsProvider. The FAQ has some more info, but the summary is that provider does:
This extension point is used to contribute a new Language Settings
Provider. A Language Settings Provider is used to get additions to
compiler options such as include paths (-I) or preprocessor defines
(-D) and others into the project model.
CMake has an option to generate .cproject as part of its configure state, so you could do something similar. See the CMake Wiki for inspiration, but the summary is that you don't store and .cproject/.project in source control and have CMake (or waf in your case) generate the IDE specific files.
You could also just pick up the build settings using the build output parser and ignore the DEFINES.txt altogether. That requires running the build once from within Eclipse for CDT to see all the commands, and requires the commands to be parseable in the build output.
I want to use CDT parser in a project. The project would be a command-line, stand-alone project, i.e., not an Eclipse plugin.
All solutions that I've seen requires using a IWorkspace. But, I want to use the CDT parser on single files outside eclipse. Is there any way to do that?
It depends what you mean by "without Eclipse".
CDT's code is built on top of the Eclipse Platform, so you're going to need to be running an application that includes the Eclipse Platform. However, there's no reason that application can't be a command-line application. These are called "headless" applications in the Eclipse community, and you can find many tutorials for making one (here's one).
Requiring an IWorkspace shouldn't be a problem. You can e.g. create a workspace and a project in a temporary folder, and copy the code to be analyzed there.
If, for some reason, you really want to use just CDT's parser in an application that doesn't include the Eclipse Platform, you can probably copy the parser code from CDT, and replace any dependencies it has on the Eclipse Platform with your own implementations. However, this is likely to be a more labour-intensive approach, and I wouldn't recommend it.