I recently joined a large C++ project that where the codebase is housed in Clearcase. The primarly build system is make, which is also in Clearcase. The builds are unwieldy and long, so I would like to use the Clearcase plugin for Eclipse to select a small subset of files for an Eclipse CDT project I can use as an alternative build system for active development and debugging.
Is there a robust way to do this? The Eclipse setup is Helios SR2 running on Linux.
First, a general advice: use snapshot views, not dynamic views, for your compilation, especially if you need to access (for linking purposes for instance) large binaries: the compilation will be faster.
Plus, in a snapshot view, with its loading rules, you will select the subset of files you actually need to see and work on.
The other way to fasten a compilation (if you haven't the need to access large binaries), is to use dynamic view this time, but with clearmake instead of make, allowing for ClearCase to record the DO (Derived Object): see "ClearCase Build Concepts"
In answer to my own question, one can create a project by way of File > New > "Makefile Project with Existing Code". The "Import Existing Code" dialog appears where one can enter a root folder path.
Related
Eclipse has projects, what's the purpose of the Workspace that appears to group projects? Projects could live in the directory tree isn't that a more natural way of organizing different projects?
When you first start up Eclipse not knowing much about it, it feels like an unnecessary layer of bloat that new users have to get accustomed to first. You're forced to set up some organizing structure that, although specific to Eclipse, wants to live in the rather general-sounding place ~/Workspace.
The workspace is a collection of projects and the metadata that cannot be included in a project because it's not portable (references paths and resources on a specific system) or because it pertains to Eclipse as a whole.
Without the workspace concept, opening a project in Eclipse would be followed by multiple steps of getting things configured. This information would be lost when Eclipse is closed or all projects you ever work on would have to share the same configuration.
Examples of metadata stored in workspace:
Locations of available JDK's and JRE's. The project references a JRE by name, the workspace metadata is needed to resolve that reference.
Locations of application servers.
Path variables.
Open perspectives, layout of views, etc. Consider one application where you need Git and app server vs another application where you need SVN and Android development tools. The views you'd want to keep open and how you'd arrange these views would be very different for two applications.
I have a collection of C++ projects that use managed makefiles inside Eclipse. I build them all, and run an existing deploy script to place all the compiled results into a target directory on the system.
I'd like a way to automate the build process without having to open the IDE, but due to external constraints from the project owner, I have to use managed make.
Once I kickoff a build for the first time inside the Eclipse IDE, the Debug / Release directories are created, and the makefiles are autogenerated. Once they are all present, I can call make from the command line, across all the projects, run an overall deploy script, etc. This will work up until the point that code changes would cause the makefiles to differ (adding/removing source files, or changing build parameters) The big problem with this is that it requires me to open eclipse and manually cause the generation of the makefiles.
I see two options:
Check the generated makefiles into revsion control (even though they're generated, I know), and commit them whenever they, after generation, have differed from the previous content.
Find a way to either open eclipse in a scriptable way, and cause makefile generation, or to find some alternate way to generate the makefiles from the .project files.
Option 1 is obviously subject to problems if I or other developers don't remember to commit the files, or if we update the Debug makefile but not the Release makefile, etc. It also makes me feel dirty to commit a generated file.
Option 2 seems much better, if its feasible.
Does a method to do option 2 exist? Are there other options I haven't considered?
I recognize similarity with a continouous integration server, but This is not the same use case. Essentially I'm building a package that gets installed on a development system as a testing release of a system library. So I'm operating as a developer, I just want to reduce variance out of the deploy process itself.
Is the file .settings/org.eclipse.jdt.core.prefs part of the project or is it part of my personal eclipse configuration?
Should I add it to version control?
Yes, you should. If this file is not under version control, then you cannot create reproducable builds of the same project, because it is no longer self contained, but depends on your specific Eclipse installation and its settings.
If you import this project into another workspace (on your or any other machine), it may behave completely different, as the compiler compliance settings, the compiler warnings configuration and a lot of other stuff is suddenly missing or different. Chances are high that such a project suddenly shows warnings/errors in the new workspace, while it was completely fine before.
Note: This all also requires that you actually configure all Java related settings in the Project properties. Never use the Java compiler settings under Window -> Preferences if you want to have self contained projects.
Just to give a concrete example: If you have configured your projects compiler compliance level to Java 6, because you are using Java 6 specific features (like Override annotations on interfaces), then the project will create a lot of compile errors on other peoples machines. This is because the default compiler compliance level in every Eclipse workspace is Java 1.5, and in Java 1.5 that Override annotation is simply not allowed.
This doesn't have anything to do with whether you are developing closed source or open source, as indicated in the other answer.
Contrary to #nitind's opinion, no. You should not put any IDE-specific settings under version control. Except you are developing IDE features or plugins.
In case you really have mandatory team-wide IDE settings, putting them under version control would be a good idea, but IMO having mandatory team-wide settings is not a good idea in itself.
For all other cases, shared IDE settings are bad for portable builds, even with the same IDE, and useless at best for users of other IDEs.
EDIT: I should differentiate, depending on the target group of your project. If you are developing a closed source product in a team that works with eclipse, then keeping these preferences under version control is helpful and a good idea. If you are developing a library, closed or open source, or an open source project, I consider ignoring the preferences more appropriate and polite.
EDIT2: I'm afraid #Bananenweizen is misunderstanding what I am trying to say.
I know that these settings are the eclipse compiler settings. They are still IDE-specific in the sense that they won't have any effect in Netbeans or IntelliJ as they won't have any impact on ant or maven builds from the command line.
Yes, leaving these setting out of version control can bring you many red wavy lines in eclipse on a different machine. It won't, if it's a maven project with a set source level by the way, I'm not sure about ant.
Eclipse is not building the projects by itself - it builds them with ant if it's an eclispe or an ant project, or with maven if it's a maven project. Both ant and maven have specific settings for the source version that do not depend on IDEs.
And this is where these settings ought to be - in the build file. And the build file should be under source control. The exceptions I mentioned earlier still apply.
EDIT 2020.03.15 #howlger informed me that the usability of these formerly eclipse-exclusive files has improved. They can be used in VSCode and maybe IntelliJ. This improves their chances of being useful across IDEs and may change your decision towards sharing them.
IMO, the files are mixing concerns. While I support source level and code formatting as being part of the build, I consider issue highlighting rules, save actions and similar concerns to be out-of-scope. If possible, I separate those, sharing the former by putting them into the build definition, but not the latter.
Here is the problem with putting it under version control....
If you import and open a project, Eclipse insists when IProject.open(...) is called on touching the file in the .settings folder... and this is before you can register the team provider on the IProject object. That means validateEdit won't fire and you get annoying errors whether you click "yes" or "no" on the popup asking "do you want to make it writeable?" That's all well and good for optimistic file-locking providers, but no so great for the "pessimistic" ones. For us this is just been yet another eclipse annoyance.
If it's up to me, there is no way I'd put these in source control.
The answer is "yes" and here you find the motivation for it and the proper way to do it: watch the talk "Committing IDE meta files: misconceptions, misunderstandings, and solutions." or look at the corresponding slides from EclipseCon Europe 2015 by Aurélien Pupier #apupier (Senior Software Engineer, Eclipse specialist).
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)
I have a bit of code for a dll that is needed by two or more projects in eclipse. Currently each project has a copy of the code and builds the DLL separately. I want to separate the dll code into a separate eclipse project so there is a common location. But I want to avoid the situation where we have to build the dll in the one project, then copy the dll back to the other projects and check the dll to each respective project. This will create a dll for each project that isn't traceable to the exact code that it was built with.
Is there a way to somehow symbolically link the dlls to another eclipse project that is using CVS as the version control system so that it is possible to tell which version of the code was used to create the dll? Am I making this too complicated or missing something obvious?
I thought about working sets in the package manager for eclipse, but I have to investigate more on how to use them with CVS to avoid making it a nightmare for the next person who checks it out and can't figure out why their project won't compile.
Thanks.
What about creating a new folder in a separate project. In the advanced section of creating a new folder there is an option to link to another location on the file system.
Or you could also create a container project that makes use of a projectset.psf file. Have the projectset file link to the different projects in your repository. When you want to check out that project, check out the container instead and right click on the projectset file and select Import Project Set...
If you are working with one workspace, you end up with three projects, each mirrored in CVS: One is the dll, the others are the projects using the dll (configured as a project dependency of these projects upon the dll project).
With three projects I wouldn't aim for working sets - they are good for managing a lot of projects within one workspace, for three projects, I'd consider them overkill. I usually tend to aim for several workspaces instead of working sets.
Regarding the next person working with these projects: You need to keep some kind of documentation about how to setup your projects. You might say that your eclipse project files do just that (as they define a project dependency upon another project) but this is for the machine - humans tend to like other communication means.
If you are worried about changes to the dll being incompatible to one project (because the person applying these changes doesn't care about the other project), aim for a build server. This will build all projects and dependent projects whenever something under version control changes, run all tests, provide a build number and package it all ready for use. This way you can be sure that - whatever is in your deliverable - can be reproduced, because the buildserver is not able to make local (uncommitted) changes to the code. Also a buildserver will signal failure (either broken API or broken tests) at the moment of the last commit (well - a few minutes later) and place the burden of repairing the damage on the one causing the damage.