I have a C source repository with an Eclipse project (.project and .cproject files at the top-level). I need to build that project from the command line, so that it is integrated with our CI system.
I know that I can build an Eclipse workspace from the command line (or a specific project within a workspace), as explained here: C++ eclipse project automatic build server and here: Build Eclipse Java Project from Command Line
But what I would like to do is to build a project without having any workspace. It sounds pretty ugly to commit a workspace (.metadata folder) into the source repository.
Is there other command line options for building a project without having to specify a workspace? If not, is it possible to generate the workspace "on the fly"?
I eventually found a solution following this answer: https://stackoverflow.com/a/8908262/6289487
I was using -data command line option, the trick is to use -import.
Related
I have a project in my Eclipse workspace from Github (via File -> Import -> Projects from GIT).
However, I am unable to run the example because the only option I have under "Run As" is "Run Configurations."
After going to "Run Configurations" I click "browse" and the project that I imported from GIT isn't there.
Any ideas?
The question is already answered in the comments but I am providing this answer to possibly clear up some misunderstandings.
In order to recognize a folder as a (Java) project, Eclipse needs to read (or create) a few files for each project, like .project and .classpath. If you do not have them in your project, or do no create them during the import, then Eclipse just imports it as a resource, or a dumb folder.
If your project is tracked by git and is also a maven project, you can clone it locally with Git (command line or GUI tool) and then "Import as existing Maven project" in Eclipse. This will use your pom.xml to create the two files mentioned above and your project will be buildable.
Alternatively, if you have already imported it as you described in your question, you can right click on your project on Package Explorer and choose Configure-->Convert to Maven Project. This will create the .project and allow you to build the project using Maven (right click->Run as..-> Maven build) and Eclipse's incremental builder (where necessary). If your maven project builds an executable, the option to execute it will also be available in the Run as.. menu.
If you have a more complex maven project (like an aggregate pom), and want a Run Configuration that runs a specific program, you will have to write it yourself by opening the Run Configurations window and explicitly referencing the java class.
Don't import the project using git clone. Download it as zip file and extract it. Add it using Project>import> General> Projects from folder and Archive.
Provide path of extracted folder into import source and finish and go to eclipse and clean and build safely run and right click on project and run it.
It should work
Generating eclipse project file from a cmake based projects works really good. We no longer need to commit eclipse project files to the repository.
But what is with the project specific settings like 'code style'. In a fixed eclipse project I could save and commit this setting. Is it possible within a cmake based project with generated project files for eclipse?
I do not see a solution to this as cmake completely regenerates the project. That's the reason why I use Makefile projekts with eclipse. I don't see any drawback of this as eclipse can easily trigger the make command.
I'm trying to re-familiarize my self with the Eclipse environment and ant integration.
Question is: how to keep my sources dir + build.xml separate from the workspace?
What I have is
a small java project and its build.xml file with all the sources placed under a separate
project folder. I then started Eclipse and let it import my project via
New Project -> "Java Project from existing Ant Build File"
All went fine, until when I wanted to build the project from inside Eclipse using build.xml.
Ant starts complaining about not being able to find the source tree. After I examined
the workspace I found that Eclipse had copied the build.xml into the workspace, so it's
obvious that ant couldn't find any sources there. They are still under my project director
and I do want to keep them there, if possible.
so whats the best way so make this setup work? workspace on one side, my project on the other?
Thank!
edit: Is what I want even possible ?
Instead of using "Java Project from Existing Ant Buildfile", just create a simple "Java Project". In the wizard uncheck "use default location" and enter the path (or browse) to the top level directory of your existing project (i.e., where your build.xml is). True, eclipse will create .project and .classpath files in your project directory (if they do not already exist), but the project will remain outside the eclipse workspace.
Case in point, this setup has worked really well in a very particular situation on a standalone system where the source tree resides in a common location but each user has a workspace in a protected location. Using the method described above, each user of this system can create a project in their own eclipse workspace, execute ant targets and subsequently remove the project from their own workspace without affecting other users' workspaces.
What about using links?
Windows Symbolic Links
Linux man page for ln
I do this all the time in C++ projects (no Java, sorry, but I think the concept is portable).
I have my workspaces in ~/workspaces/{workspace_name}. I have a single shared project file in ~/{my_projects, and then the source trees (multiple versions) are in ~/proj1, ~/proj2, etc.
Within each ~/proj* directory, I put a symlink to ~/my_projects/.project and .cproject (required for C++, not used in Java). So each source tree is sharing the single project file. Then in each workspace (one for each source tree), I configure the workspace by importing the project link. For example, ~/workspaces/proj1 imports ~/proj1/.project, but ~/proj1/.project is actually a symlink to ~/my_projects/.project.
So this keeps the source separate from the workspaces. When building, there's no real configuration to do -- I just have Eclipse run make in the appropriate node of the tree -- we already have our own command-oriented build system (we're not using ant, but the same principle should apply).
I source-control the ~/my_projects folder in a private area of the SCM, so other team members don't see it or fiddle with it -- many of them don't use Eclipse at all.
There isn't really any need to try and avoid Ant and Eclipse using the same set of source files. In fact, its probably better that they do use the same set.
Bear in mind, you're not actually mixing anything. There is just one set of source files and then there are two different ways of building it; Ant and Eclipse. These builders are independent of each other, so there is no problem with being coupled to Eclipse. You can even happily commit all the eclipse files (.classpath, .project, .settings) to source control without affecting any developers who use a different IDE.
I do this all of the time (admittedly using maven, not ant), but the same principle applies.
If you have an existing project in Eclipse (with the .project in the source tree), then you can Import Project->Import Existing Project. When the dialog box comes up, you can choose to 'Copy projects into workspace'. Make sure this is unchecked, and them import.
You still store the .project in the original source tree, but thats all.
So now I have
code/xxx (which contains the .java files, which are in SVN)
code/xxx-workspace (which contains the eclipse workspace)
I am working on a cross-platform C++ project with 8 other people which uses the following libraries:
OpenCV Library
Boost C++ Library
The project is inteded to be cross-platform so all users have agreed not to use platform-specific code, and, to keep things as simple as possible, all users will be using Eclipse as their IDE. However, some will be using Eclipse for Windows while other will be using Eclipse for Linux.
Since the project will be hosted on SVN, we would like to avoid conflicts with different configuration files (like make files, eclipse project files etc..) which are shared. We would also like to share as much of the configuration files as possible through SVN, to keep the configuration as simple as possible.
Let's assume that all users have properly configured system variables and installed the required build tools (such as make, cmake etc.), and have configured their Eclipse settings configured properly (but not the project-specific settings).
How to configure the project once and what of the configuration files to share on the repository, so that both Windows and Linux users can compile it without modifying configuration files retrieved from the SVN repository?
(I am not looking for the complete solution which would specifically work for those 2 libraries I mentioned, so I would appreciate a general how-to step-by-step explanations which would enable me to easily add another library.)
General discussion:
You will need to install Cygwin or something similar to it to make GNU Autotools toolchain available to Eclipse on Windows:
How to deal with Eclipse CDT+Cygwin?
Once your toolchain, Eclipse, with CDT and SVN connectors are ready on your development machines, go through the following steps.
Open Eclipse and switch to CDT: Click Window->Open Perspective->Other... and select C/C++
Select: Eclipse->File->New->C++ Project
Project name: viewer
Select: Project type->GNU Autotools->Hello World C++ Autotools Project
Click: Next
Click: Finish
Right-click in Project Explorer: viewer->Reconfigure project
Click: Console->Display Selected Console submenu-># CDT Global Build Console. If "autoreconf -i" output is nominal, proceed to step 9. If Console reports: sh: autoreconf: command not found, then add the path to the autoreconf command to the Project Build Environment:
Right-click in Project Explorer: viewer->Properties->C/C++ Build->Environment->Add...
Name: PATH
Value: path_to_autoreconf:${env_var:PATH}
Click: OK
Click: Apply
Go back to step 8.
Double-click: Project Explorer->viewer->src->viewer.cpp
Add some code:
include <opencv/cv.h>
include <opencv/highgui.h>
include <cassert>
int main(int argc, char *argv[]) {
assert(argc > 1);
CvMat* img = cvLoadImageM(argv1);
cvNamedWindow("Picture", CV_WINDOW_AUTOSIZE);
cvShowImage("Picture", img);
cvWaitKey(0);
return 0;
}
Double-click: Project Explorer->viewer->configure.ac and enter the following code below AC_PROG_CXX.
AC_CHECK_LIB([opencv_core],[cvSetZero],[],[])
AC_CHECK_LIB([opencv_highgui],[cvShowImage],[],[])
AC_CHECK_LIB([boost_regex-mt],[regexecA],[BOOST_LIB_SUFFIX="-mt"],[BOOST_LIB_SUFFIX=""])
AC_SUBST(BOOST_LIB_SUFFIX)
Double-click: Project Explorer->viewer->src->Makefile.am and enter the following code.
>
bin_PROGRAMS=viewer
viewer_SOURCES=openCvFocusIssue.cpp
viewer_LDFLAGS = -lboost_regex#BOOST_LIB_SUFFIX# -lopencv_core -lopencv_highgui
Repeat step 8, autoreconf (Reconfigure project)
Click: Project Explorer->viewer
Build project by clicking the hammer in the toolbar. If you do not see the hammer, Window->Open Perspective->Other... and select C/C++. If C/C++ does not show up, install the CDT.
Click: Project Explorer->viewer and then Run->Run, then in the Run As window->Local C/C++ Application, then in the Launch Debug Configuration Selection window->gdb/mi and press enter. You should see Hello World.
Quit Eclipse and navigate to the viewer project directory.
On the command line, issue make dist
Ensure you got a viewer-1.0.tar.gz or similarly named file, and then remove it: rm viewer-1.0.tar.gz
On the command line, issue make clean
In the same place, issue make distclean.
Navigate to the workspace directory that contains the viewer project.
Move the entire viewer directory to the directory that contains the svn checkout you want to place the viewer project in.
Change directories to where you just moved the viewer.
svn add viewer && svn ci -m "Added eclipse-autotool project"
Open eclipse and make sure that you have an SVN connector installed.
Remove the "viewer" project from the Project Explorer view.
Open eclipse and add this SVN repository checkout to the Team perspective.
Import the viewer project from your SVN repository checkout.
Switch back to the C/C++ perspective and have fun.
Two suggestions:
Use cmake: I love this tool. There is a bit of a learning curve but
if you get it right all the project will include is the cmake files
and when a person first checks it out they run cmake to generate
their makefiles (or VC++ project files, etc) with all the different rules for linux or windows one
might need.
or
Check in a basic config for the project, then add those configs to the git/svn ignore so no one ever checks them in again, then when you checkout for the first time you have to get your config running but after that it won't be overwritten.
I guess this is a Eclipse question.
I have a mercurial repository with a source folder (src/main/java/) and some source code. The repository also contains a build.xml. After cloning the project into Eclipse using the Mercurial plugin I'm unable to configure a launch configuration for my project. Eclipse is unable to identify the newly cloned project as a project when setting up the launch configuration. What am I missing?
TIA
What kind of launch configuration are you using?
an External Tools Configuration (in which case you defnie and Ant Build with a direct link to your build.xml)
or a "Run Configuration", meaning your repository must include a .eclipse and a .classpath for eclipse to list your project as one being able to Run.
As discussed before in Which eclipse files belong under Version Control, those two files can be versioned, provided they only use relative path.
Do you have a .project file?
If you do, you should be able to use File->Import->General->Existing Projects into Workspace.
If you don't, try File->New->Project and there are various different options to create a project from existing source.