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.
Related
I want to import a maven project from GitHub into intellij which in of itself I know how to do however, the project this time was created initially also as an eclipse project and I want to be able to work on it in idea while my team members work on it in eclipse without causing conflicts due to differing project file structures. How can this be done?
When checking it out in Intellij it does ask me if I want to create a project from it and select yes but next, it asks whether to create the project from the existing sources vs from external model. From the external model option it allows me to pick eclipse or maven but not both. Do I just create from existing sources? Which is my best option to do this without screwing it up for the others when I commit and push my changes?
I understand that the easy answer might be: "just use eclipse" however, I think the answer on how to properly do this could be useful later. Not only me but also for others who want to work with the IDE they are most familiar and productive with and not mess with the workflow.
Any help would be appreciated
When importing an Eclipse project into IntelliJ, you have the option to:
Create module files near .classpath files
Keep project and module files in
The idea is to keep your *.iml file concurrently with your Eclipse .project/.classpath (and you can keep them in sync).
That way, you can open the project in both IDE.
All!
In our project team, people use either IntelliJ or Eclipse IDE depending on what they are comfortable with. Eacf of the IDEs have their own settings files. For instance, IntelliJ uses .idea and .iml and Eclipse uses .project, .settings, .classpath! While some other stack overflow thread says it's not needed to check in any of these files from either IDEs if you are using Maven, I'm unsure why that's the case. None of the threads say why using Maven does not warrant (some of) the settings, .project, .classpath be checked in?
Can someone help me understand 2 things
1) Why don't we need these files to be checked in when using Maven?
2) If we must check in (Assuming Maven is not used), how do we ensure that either IDEs work okay when checking out from source control and what to check in to ensure cross compatibility.
Thanks!
1) These files are not needed because bothe IDEs can import maven projects using the pom.xml file. So the pom.xml file is your single source of project description for both IDEs.
https://projects.eclipse.org/projects/technology.m2e
https://www.jetbrains.com/help/idea/maven-support.html#maven_import_project_start
2) You see it right, it's hard to ensure cross-compatibility if you use only the native project files of the IDEs. Among many other things that's why it's encouraged to separate the build chain (Maven, Gradle, etc.) from the IDE. Also continuous integration systems can be configured more easily if a unified build tool is used so it's kind of a best practice to use one and keep it independent from the IDE.
In case you don't want to switch to maven now, check in the Eclipse .project and .classpath files, Intellij is able to understand them.
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.
I'm working on an open-source cross-platform C++ project that supports Make and Xcode builds. I'd like to add an Eclipse project as well, but there seems to be no double-clickable way to import a project into Eclipse. Consequently, my "project" consists of fact that I have .project and .cproject files checked into the repository.
torc/
trunk/
eclipse/
??
sandbox/
.project
.cproject
...
src/
.project
.cproject
...
xcode/
torc.xcodeproj/
...
...
Suppose somebody downloads the code but doesn't use Xcode. They can build the code with Make, but many people will probably want to peruse the code structure and sources, and Eclipse would provide a great way to do that.
Unfortunately, the user may not be familiar with Eclipse or how to import projects, and I'd like to make things easier for them, not harder. I was hoping to provide something double-clickable or draggable that would get them started with minimal grief. Can anybody suggest a good way to do this? Or is there an alternate approach that would feel natural to current or prospective Eclipse users?
I am aware of this approach, using org.eclipse.cdt.managedbuilder.core.headlessbuild, but that seems to work primarily with never versions of Eclipse and CDT.
I have an answer, but it's not very pretty.
You could create a workspace directory for your project in your repository and check it in with the project already added to the workspace. Then, you could create a script which launches Eclipse and tells it to use the workspace directory in the repository. (For example, eclipse -data ./eclipse/workspace.) You should make sure the workspace has been cleaned first because a workspace that has been built can contain quite a lot of extra metadata.
That said, this is not a great solution. Experienced Eclipse users will probably not want to use your workspace because preferences are stored in the workspace, and besides, if they see a .project and .classpath file, they're already going to know how to import it into their own workspace. People unfamiliar with Eclipse are likely not to have Eclipse installed at all.
I think it is quite normal to have more than one binary in a project. However, with Eclipse CDT I don't know how to set up the IDE to get things done.
I know I can create several projects - one per binary. And I know I can set the dependencies per project. However, I cannot regard them as one project in Eclipse. If I'd like to share the code with a version control system (like svn), each developer has to import the projects separately.
What I miss is something like the Solution (sln file) in Visual Studio. Should I create a single project and create the make files by myself?
I haven't tried it out yet, but there is this 'project set' which can be ex- and imported. Is this the solution? Can this be put into version control?
My goal it to put everything under version control, not only subprojects. I cannot imagine that CDT makes only sense for single-binary applications.
How can I work properly?
I am quite sure CDT doesn't support sub-projects, which leaves you pretty much with:
one workspace per "set of projects"
one project per binary (like you mention in your question)
project dependencies (like you mention in your question)
In term of version control, that means:
submodules (Git),
subrepos (Mercurial) or
external (SVN)
for each project needing a shared library project.
In short, that means putting under version control various components (set of files), with one referencing specific version of others (that list of specific versions of other components is called a "configuration", based on a component-based approach development)