We have a a product developed on Windows for years. The product is composed of one Eclipse workspace and about 20 projects.
On Windows, we ask every developer check out projects into d:\dev\product folder, and copy a unified Workspace to d:\dev\prod_workspace. This way, whenever a new machine is set, we simply copy files to the same folder, and we can start working immediately.
Now we need to move our development environment to Linux and Mac. But there's no D:\ on Unix. And home folder for Linux is mostly like /home/username and /Users/username for Mac. We found Eclipse keeps absolute path in workspace when referring to projects, so simply copy workspace over does not work anymore. Even when we manually create/configure workspace on a Linux machine, it still cannot be copied over to another user, because the absolute path is changed.
I guess our goal is to allow easy setup of development environment. Do you have any suggestion to move eclipse workspace around?
I develop an Eclipse based product for Mac and WIndows (haven't tried Linux).
The solution I found to work best is to actually go and manually check out the projects in the workspace on each machine directly from source control. While the project structure does convert between platforms, any attaches, such as version-control stuff does not. I am not sure why, but I guess each thing has its kinks.
You may be able to able to hasten things a little by creating a project working set (or whatever it's called, I think it's a PSF file) for a platform, and then reuse it on all platforms.
Another problem is that Eclipse versions are not 100% compatible. One of the problems I have is with manifest files for plugins, which have different semantics (e.g., what to do with exported packages that don't actually exist) in each platform, causing a headache.
Finally, be away that Java on Mac and PC are not identical. In fact, Eclipse has two versions for the Mac. I usually end up running and compiling on Java 5 on the mac, which does have some incompatibilities with Java 6.
I have ported my eclipse project from windows xp to RHEL(never tried Mac)
Your task can be accomplished in the following steps :-
Use workspace variables in your project code rather than absolute path.
Shift your workspace to some location in linux as /Workspace or if you want to keep it user specific make the workspace folder as /home/user_name/Workspace.
There is an option to change all the \ of windows to / in linux. The option can be found under the file menu in eclipse.
Change the settings of where to find classpath directories, the options can be found by just right clicking on the project menu in the project viewer panel.
There is an option to build the project clean from scratch. You just have to click on the option and eclipse would re-compile the project.
Once all this is done, and all your database connections have been successfully ported to linux, you would have a working project running in linux as well.
I can think of two ways to do this:
Use workspace variables in Eclipse to point to the exact location where the workspace sits, if you need that. Then the developer can put everything in the workspace on Windows, Unix, whatever, then define the variable and you're done, or
If compilation is always done from within Eclipse, meaning you don't truly need any absolute paths anywhere, then change the projects to all use relative paths and check the Eclipse classpaths, etc, into source control. Thus, when a developer checks out everything in Eclipse, the classpath and .project file will be at the root level in the project and all paths will be pre-defined.
For option #2, you may need to have multiple .project or .classpath files, and have the developer copy the appropriate one into location. That is, copy .classpath.win into .classpath for Eclipse's use.
If you check out the projects from a source repository, then consider using Team -> ProjectSets to handle these.
Preferences can be saved in a file and loaded.
We tried classpath variables and loathed them. Now we just have everything in single projects in the source repository.
Use the Workspace Preference Transferrer plugin
This allows you to transfer the workspace settings from a given workspace to another via new options in the 'switch workspaces' dialog.
I'll share my own solution:
Zip the workspace. Just zip the entire file and then transfer it over. Then, all you need to do is delete the default drive reference:D:\ ...or whatever ends up appearing in the beginning of your file name. Then all you need to do is drag it over to the new empty workspace on your newly downloaded Eclipse.
Related
I've got a solution in which I'm trying to create a 2nd executable. These two executable share most of the same files, but have a few different ones including resources and application icon, etc.
I created the 2nd project, and added the items as links.:
Right-click "Add existing item",
Browse to it,
Click the "Add" drop-down and select "Add as link".
Adding as links means that it just references the other file in the other folder and does not copy it.
Now, when I tried to commit my project VisualSVN / SVN tried to do an SVN add on those files in the logical path they belong to resulting in lots of errors that the file was not found. It caused the entire commit to fail and was a major pain in the ass.
Is there a good way I can add links to files without side-effects? All the files I'm trying to link to are already in the same repo.
Update
Maybe I should add more information about what I'm trying to accomplish because I'm open to any suggestion which helps me accomplish it.
I have a project structure something like this... Or I want it to be like this...
MyProject
/Common
BusinessDataObjects (svn:external)
ControlsLibrary (svn:external)
OtherCommmonLib1 (svn:external)
OtherCommonLib2 (svn:external)
/Modules
Module1
Module2
Module3
...
Application1
Application2 (shares all App1's files, except different .resx, icon, name, other minor differences)
SetupProject1 (includes app1 and certain module dlls)
SetupProject2 (includes app2 and certain module dlls)
The application is basically an empty shell (using Prism) which loads the modules installed in a /modules folder. I want both applications to be almost identical, but I want them to have different names and a different icon. I thought I could accomplish this by adding the files from the first project to the second as a link, and simply swapping a resource file which included the strings for the application window title, About dialog, etc. But then VisualSVN or whatever tried to SVN Add those items which I wasn't expecting.
I need to be able to develop the modules and the application's shell project. They are not stable in any way yet. I just want them to near copies of each other but with minor naming differences. I figured with two application projects, I could have two setup projects that included the output from each application and whichever modules are supposed to be included in that version of the software program.
I was trying to make this as foolproof as possible, and I'd like to avoid having to update external references to the same project. (I'm a bit confused about that as well, would I svn:external to the same repo?) That doesn't sound good, but this was my main idea on how to create two almost identical apps. I'm not sure how else I'll do it if I can't get my version control software to behave.
I had suggested oringally we only have one version of the software and have certain modules be upgrades, but there are some good reasons they can't really do that.
When you add a file to a Visual Studio project with "Add as link" it's expected that the file is not copied to the project's folder.
VisualSVN considers status of items in your working copy, even files which are not included in the current solution. However a linked file does not exist in a working copy, thus can't be tracked. It's out of version-control.
Since the files you attempt to link are already version-controlled (i.e. they exist in the SVN repository) it makes sense to use Externals Definitions (svn:externals property) to link them.
Also see TortoiseSVN Manual; it's description of svn:externals is really good.
You don't mention your environment. However, you mention you have a Solution. I'm assuming it's VisualStudio you're using.
Have you tried AnkhSVN which is a Source Control Provider for Subversion for VisualStudio? AnknSVN integrates into VisualStudio much like Microsoft's native version control systems of Visual SourceSafe and TeamFoundation. I believe you can use AnknSVN to do the linking you want since these links are really internal VisualStudio structures and not actual symbolic or hard links like you find in a Unix system.
I usually avoid links (I believe they're called Junctions on Windows) because they simply don't work across operating systems. Instead, you can use one of the following methods:
Use your build system to copy the files, or create the required links rather than your version control system.
Use svn:externals to do the linking. Careful with this because svn:externals are pointers to a Subversion URL.
For example, if I setup http://foo.com/svn/trunk/proj1 to have a svn:externals link to the head of http://foo.com/svn/trunk/proj2, and I create a tag for Project 1 by copying http://foo.com/svn/trunk/proj1 to http://foo.com/svn/tags/REL-1.2/proj1, that project is still pointing to the head of the trunk of proj2. Changes in Project 2 will change what I thought was a stable tag. Always point your svn:external to a stable revision.
I have no experience with VisualSVN, we use Ankhsvn which does not have that problem.
http://ankhsvn.open.collab.net/
I am wanting to setup a project and potentially an existing project to be SVN version controlled. I am using uberSVN for the svn server. I have installed AnkhSVN for visual studio.
Currently, the team I am working with is using visual source safe and one of the problems we have is when someone adds a reference to a DLL, it modifies the project file as you would expect, but our paths are different between different team members (XP boxes, 7, you get the idea). What I was wanting is making the project file ignored when checking in/out so that we don't mess up the references for everyone else.
Is there a way I can make SVN ignore these files within the plugin? One of the side effects of this is a person would not know if a new file has been added in the project as this modifies the project file. Other than telling everyone "hey, you need to manually add this file to your project," is there a cleaner way of doing it?
If you copy the DLL to a folder inside your VS solution folder before linking to it, I think the project link will be relative not absolute. So you can check the DLL and the updated VS project into your configuration management and everyone should be able to share it.
You should start using virtual paths for development work; that way each team member can keep work-related files at any physical location but the virtual path (the one seen by tools is always the same.
For example, my team does all work under Q:\. My physical source for work is under physical path C:\Work\<project_name> where the project_name part depends on the project. When I want to work on a given project, I map the Q:\ virtual path to the right physical path using
subst q: c:\work\project_name
When I need to switch, I run a similar command. This way there's no need to worry about different paths on different computers. This worked very well for the whole team and eliminated most issues you describe above. The only thing you need to make sure is that everyone always uses the virtual path (Q:), not the physical path when dealing with project-related files. For my team it took about a week to get used to that, after that there were no more problems.
Your project file is an important part of your project so ignoring it in the source control tool will eventually lead to problems. I recommend you don't do it (even if you can).
Edit:
If you have DLL-s in different physical folders on different machines, the best choice is to copy those DLL-s (and their dependencies) to a known location. It's fine that they can't run from there, as long as the compiler finds them.
This known location could be inside your virtual path or a common physical path (if the same DLL-s are needed for multiple projects). You can use Dependency Walker to determine what dependencies you need for native DLL-s and Reflector for .NET DLL-s.
If the size/number of DLL-s is so large that creating a copy is not an option, you can actually tell AnkhSVN to ignore certain versioned files when committing changes. Right-click the file, select Subversion > Move to Change List > ignore-on-commit. After this the file will show up in the commit dialog unselected but you can still commit it if you manually select it.
I need to reference a project in a Xcode workspace by an environment variable. An Xcode workspace file might look like this:
<Workspace
version = "1.0">
<FileRef
location = "group:../../Some/Dir/SomeLibrary.xcodeproj">
</FileRef>
<FileRef
location = "group:SomeApp/SomeApp.xcodeproj">
</FileRef>
</Workspace>
I want the SomeLibrary project to be referenced by an environment variable, so that the workspace file and projects can be used in different developer environments (the lib project is shared between several different projects). Any ideas on how to do this? Is the XML-format documented somewhere?
Thanks! :)
In your XCode 4 Preferences, you'll see a "Locations" tab and in the "Source Trees" section you can put an environment-variable like location (which you can change from machine to machine). And you can use these settings to change paths for the libraries you're trying to include or reference in your projects.
It's not exactly the environment variable from the Terminal command line, but then again most people don't launch XCode from the Terminal and so you shouldn't expect to pick up your $PATH or other UNIX-style environment variables from double clicking on any app, much less the XCode IDE. It's a good alternative.
There's some more information in this related question and here's Apple's documentation on what they are and how to set them up (which is aimed at XCode 3 but the same concepts apply for XCode 4).
Let me know if I can provide more information, and I hope my answer helps!
I think I need to answer this myself. Based on my research it is not possible to use a dynamic location (environment variable, source tree, etc) on workspace projects.
Solution 1:
You CAN achieve what I'm trying to do using symlinks. In my current workspace I've created one application-project, and a project entry which points to a symlink on the local file system. This way one can switch projects and have dynamic locations for the library-projects. I'm not sure if XCode treated this link properly when adding, so I manually added the project entry like this:
<FileRef
location = "group:Libraries/SomeLibrary/SomeLibrary.xcodeproj">
</FileRef>
Where SomeLibrary (IMPORTANT: The folder SomeLibrary need to be the symlink, or else XCode wont be able to find the project contents) is a symlink to my static library project somewhere else on the local file system. This way, developers can have different paths to the library, and one can easily switch versions when needed.
Solution 2:
Adding a static library project as a subproject and using cross-reference. For sub-projects, one can use Source Tree and use dynamic locations.
I haven't tested these solutions widely, so I'll come back with a reply after using it for a while.
I created a Netbeans CPP Project in my Mac and uploaded it into git. The project has collaborators who use Windows.
When I pushed my project into github , I pushed the makefile information too (the whole project). Now the collaborators are getting build errors because the reference contains my Mac filepaths.
The Windows machine have cygwin installed.
How do I resolve it ?
How I do make it platform independent ?
What should I (and collaborators ) do to not affect the other workers ?
ANSWER : Netbeans has an option (in the project properties under c++), to have the file path as absolute or relative. So I all had to do was, set the relative option and push the changes . The project started working for everyone ! VOILA !!!!!!!!
Netbeans has an option (in the project properties under c++), to have the file path as absolute or relative. So I all had to do was, set the relative option and push the changes . The project started working for everyone ! VOILA !!!!!!!!
I've found that the project files generated by NetBeans for C++ are rather unweildy and aren't very maintainable by humans. And while they do tend to reference paths relatively from the root of the project (facilititating copying the project to different directories), there's just too many project files to maintain. And you're sol if they don't work.
I don't know if NetBeans allows you to specify environment variables for paths in the project settings dialogs. The macro/variable stuff is largely undocumented as far as I can tell. But if you know how to do that, then define all your file path dependencies by an environment variable instead of a hardcoded path in the project settings window. Remote developers need only redefine the environment vars on their machine.
But I think a better solution is to not use the NetBeans auto-generated Makefile from Project Settings. Instead, declare your own Makefile and create a NetBeans project type from "an existing Makefile". I've found that works really well.
Then you can have a line at the top of you Makefile as follows:
include common.inc
Where "common.inc" includes all the hardcoded library paths that are machine dependent. Here's an example of mine:
BOOST_INCLUDE := -I/home/jselbie/lib/boost_1_46_1
OPENSSL_INCLUDE := -I/home/jselbie/lib/openssl
And then my Makefile only references these directories by variable name. And so when I move the project around different machines with different configs, I just need to update common.inc.
And then if anyone else wants to use NetBeans to compile my project, they just need to create a NetBeans project from "an existing Makefile" option.
The option for relative file paths is actually NOT in the project properties! Instead, it's in the top menu bar.. choose "Tools" then "options" then click the "C/C++" tab, and the second box down is "File path mode" select "always relative"
I have switched to Mac as my main development machine (coming from Fedora) and was just curious as to what people used as there development folder structure. For example in Fedora I always had ~/opt for user programs ~/src for source code I was working on and ~/bin for files I constantly executed. Is there a Mac de facto. What do you guys perfer?
Thanks,
Greg
I use the directory ~/Developer as the root of my development-related files. Inside that I have ~/Developer/Code for code snippets, tutorial code, test ideas, etc. I have a ~/Developer/Projects directory to hold in-development projects. This contains a few subdirectories, including Archives for projects I've abandoned, and Current for current development work. ~/Projects is also a symlink to ~/Developer/Projects/Current.
To add to #mipadi, after a recent fresh install of OSX 10.10.2 (Yosemite) I noticed that if you create a ~/Developer folder, that folder automatically receives a special folder icon (with a hammer on it). This property seems to be an artifact of older versions of Xcode, in which it would automatically create the folder for you.
I have 3 folders in home:
Sandbox - my source control checkouts
Dev - projects that are not in source control (tests, experiments, etc.)
3rdPartyDev - 3rd party code I've downloaded and want to keep around
I try to keep as much 3rd party code around as possible. With the Mac's Spotlight feature, you can instantly search all the code at once. If there's an API I need to see example code for, I just Spotlight for it and chances are some code in there is already using it.
I have a big messy folder called "code" full of Xcode projects.
In Mac, for all developer projects there is a specific folder inside the home directory called ~/Developer, which when you create automatically has a customised icon.
You can thus subdivide using this:
Experiments: things you just want mess around with.
Public: open source
Private: private projects
Learning: If you're on a learning path to track your progress and milestones.