I code on 2 different computers with different username. Xcode makes a .pbxuser file for each one, making necesary replicate the config from each one.
This is error prone, and the files are not diff-friendly so everything must be carefully checked. Any way to avoid this?
The info in the .pbxuser file is not particularly important - it's just personal settings like window locations, breakpoints, etc. All the important stuff is in project.pbxproj and this is the only file you need to sync/back up/check into source control/etc. You can ignore or even delete the other files in the .xcodeproj directory - they will get re-created with default settings.
the .pbxuser file does contain custom executables in there. So if you use a custom executable as a unit test runner, (or some other executable) you might have to share that file
When I have Xcode projects I might have to work on on multiple computers, I just have my project live on Dropbox. Then it's in the same folder on any computer I might use to work on it, and the changes get synced every time files are modified. That way I'm literally working on the exact same project on each computer.
Related
OK, here's my issue :
I'm using Xcode 4.6 under Lion
In my current project I've added several "real" folders (either with sources or with resources) which Xcode represents as "Groups"
However, whenever I add another file in one of my already-imported folders, the file doesn't show up (but instead I have to manually drag each new file to its appropriate location).
Well, given that my project is comprised of hundreds of different files, and that files are being added constantly, this seems like an overkill.
I realize this may have to do with Xcode's Group-centric approach, but it still bothers me.
So, is there any workaround? Any ideas?
As for many IDE, it won't scan changes of new files in included folder, to prevent accidental add of extra codes that will break the compile process. If you really want to do so, write a script to add all files in the folder and run it at pre-compile stage, i.e. in Xcode, "External Target"
See: https://stackoverflow.com/a/976459/188331
I am currently working on several applications and in n some of these apps the solutions contain projects from multiple work spaces in Visual Studio 2010.
This causes an issue when others attempt to work on the code for a certain application or simply download the code and run the app. I have my work spaces for my computer defined, but others do not.
What I want to do is have a way to set up a work space or sort of work space template where anyone can download the code from the server, while on any machine and with the required folder structure, and the application will run.
For instance, if I had the following server structure:
$/
$/SolutionFiles/
$/SubFolder1/
$/SubFolder1/ProjectA/
$/SubFolder1/ProjectB/
$/SubFolder2/
$/SubFolder2/Project1/
$/SubFolder2/Project2/
...and I had a solution $/SolutionFiles/MyAppSolution that contains code from $/SubFolder/ProjectA/ and $/SubFolder2/Project1/, I want to have a separate workspace or something, possibly named "MyAppSolution_Workspace" or something like that, that will map the solution folder and the related project folders to a generic path. This would need to work and be accessible from all other separate computers and would need to keep the same directory structure from the server and have the same folder names and everything as is expected by the solution/project files.
From what it looks like Shared work spaces in VS2010 would work, but it seems to only apply to one machine and is not entirely generic.
Are there any suggestions for how to accomplish this?
You probably won't like this answer but here is what we do:
Keep your workspace mapping as simple as possible. Never move folders or rename folders or files using the workspace mapping. Then all users need to do is map from the top and everything works. They may get more files than they want but it will work.
Advanced users can use the folder cloaking ability to block getting folders they aren't interested in or can map just the folders they want. The key being that when they map specific folders instead of the root they leave the paths the same as they would be if the root was mapped.
In our system we then have our version and release branching structure above the folders of your example. So everything you've listed would be duplicated inside a MAIN folder and inside a Release_1 folder.
As I create more applications, my /code/shared/* increases.
this creates a problem: zipping and sending a project is no longer trivial. it looks like my options are:
in Xcode set shared files to use absolute path. Then every time I zip and send, I must also zip and send /code/shared/* and give instructions, and hope the recipient doesn't have anything already at that location.
this is really not practical; it makes the zip file too big
maintain a separate copy of my library files for each project
this is not really acceptable as a modification/improvements would have to be implemented everywhere separately. this makes maintenance unreasonably cumbersome.
some utility to go through every file in the Xcode project, figure out the lowest common folder, and create a zipped file structure that only contains the necessary files, but in their correct relative folder locations, so that the code will still build
(3) is what I'm looking for, but I have a feeling it doesn't as yet exist.
Anyone?
You should rethink your current process. The workflow you're describing in (3) is not normal. This all sounds very complicated and all basically handled with relative ease if you were using source control. (3) just doesn't exist and likely never will.
A properly configured SCM will allow you to manage multiple versions of multiple libraries (packages) and allow you to share projects (in branches) without ever requiring zipping up anything.
This is not a work-stopper in any way, but I thought I should ask anyway because it is a little annoying. Let's say I create a new project and start putting source files in a directory other than the default that shows up the first time. Afterwords, whenever I open the project, I have to navigate to the source directory once during that session. Like I said, not a big deal (but if solvable, then it's icing on the cake). Quite a few times I absentmindedly put the source file in the default directory and end up committing that file to the SVN and if I am lucky, going through all the files, removing them, then adding them again.
So my question is, is there any way to specify the default source directory on a per project basis?
I have run into the same nuisance. I like to put the public interface header files for a library in a separate directory, but end up with file directory typos because I forget to navigate to the correct directory when saving a new file. Unfortunately, Visual Studio does not offer a setting to change the default directory for new C++ source files.
I had the same problem when I started using build systems (CMake, Premake) which requires me to keep my project files separate from my source files, which hampered my workflow.
Although changing the default source directory seems impossible, if you aren't afraid to spend money, the workaround I found was to use the Visual Assist extension.
You can bind a shortcut of your choise to the Create File command which creates
a new file relative to the directory or your open file.
I'd also recommend to base one's workflow around the wonderful
Create from Usage command (which I think greatly boosts
productivity) which almost eliminates the need to manually create files.
The extension is great, albeit a bit costly. I would love to see Microsoft incorporate these features directly in the IDE eventually as they are found vanilla in a lot of other IDEs e.g. Eclipse, Intellij.
There might be some free extensions available that does the same thing, but I haven't found any.
Changing the Default Project Folder may help. This page demonstrates how to change the default for Visual Studio 2005, and it should be the same for later versions.
I'm new to XCode and I find the file management a huge pain. In most IDEs, you can simply have the project source tree reference a directory structure on disk. This makes it easy to add new files to your project - you simply put them on disk, and they will get compiled automatically.
With XCode, it appears I have to both create the file and separately add it to the project (or be forced to manipulate the filesystem through the UI). But this means that sharing the .xcodeproj through source control is fraught with problems - often, we'll get merge conflicts on the xcodeproj file - and when we don't, we often get linker errors, because during the merge some of the files that were listed in the project get excised. So I have to go and re-add them to the project file until I can get it to compile, and then re-check in the project file.
I'm sure I must be missing something here. I tried using 'reference folders' but the code in them doesn't seem to get compiled. It seems insane to build an IDE that forces everyone to modify a single shared file whenever adding or removing files to a project.
Other answers notwithstanding, this is absolutely a departure from other IDEs, and a major nuisance. There's no good solution I know of.
The one trick I use a lot to make it a little more bearable — especially with resource directories with lots of files in them — is:
select a directory in the project tree,
hit the delete key,
choose "Remove References Only", then
drag the directory into the project to re-add it.
This clobbers any manual reordering of files, but it does at least make syncing an O(1) operation, instead of being O(n) in the number of files changed.
I'm intrigued which IDEs you're using that automatically compile everything in a directory, as no IDE I've ever used does that (at least for C++). I think it's pretty standard to have a project file containing a list of all the files. Often you may want to only include certain files for different targets, have per-file compiler settings, etc.
Anyway, given that that's how it does work, you really shouldn't have too many problems from merge conflicts. The best advice would be commit early and often so that you don't get out of step with other people's changes. Merely adding files to the project shouldn't result in a conflict unless they happen to be added at exactly the same point in the project tree. We've been using Xcode in our team for years and we very rarely get conflicts: only if someone has restructured the project.
Fortunately, because the Xcode file format is text, it's generally quite easy to resolve conflicts when they occur, unlike the Bad Old Days of Codewarrior with it's binary format.