Say you create a project. Then you want to do something else. You want to create another project that uses all the files of the previous project. You then modify it a little bit.
In vb.net it's simple. You just copy the vbproj file and that's it.
In objective-c copying the xcproj will result in a project file that won't compile.
Solution?
Note:
I do not want to do simple copy. If I do simple copy changes will not be propagated. I want if the fork change so will the original file.
As far as I know changing the project file name will make the project fail to compile. So just copying the project file doesn't work unless I do something wrong.
I think it's utterly ridiculous that there is no easy way to make the project work after changing the name of the xcodeproj file? I can't even open that xcodeproj file in textedit. In vb.net I can hack the project file straight. Why not in xcode?
There are two options which I would prefer :-
If there are classes which are constant and are not changing, you can make library which is called as Cocoa Touch Static Library
OR
Just copy folder to another location, rename application name and changes you want to do and run it!
Hope this info helps you..
I long for the day when you can simply choose "save as template" from Xcode(!)
In the meantime it might save you some headache to check out Project Duplicator from the AppStore. I haven't tried it out myself yet, but it sounds like it's designed to do exactly what you're asking for.
If you want to do it the manually way you could duplicate the folder with all corresponding files in the Finder and go about renaming everything from there.
You can create multiple targets for your project.
look at this link.
Related
Some colleagues, now departed, had the habit of adding new classes within a related class file.
This makes refactoring painful.
Is there a tool, perhaps within XCode or AppCode or just a simple script, that will split up these monster files?
It appears there is a tool to help with this in AppCode, but it only semi-automates the process.
I'm using AppCode 2.0, I don't know if the same tool is available in AppCode 1.x.
To extract one class from a file to a new file, right-click the#interface or #implementation line and select Refactor > Move. Alternatively press F6 on that line. You can now enter a new file name, though you probably want to copy+paste the class name in here. At this point you can also select any defines you want to move.
I have done some work on a script to extract all classes in a file. I'd love to share this one day, when I get the chance to remove our clients code from the unit tests!
I don't think so there is any tool for this. However you can write your own osx application for doing the same.
The application will ask to browse the file, and it will search for #interface....#endand#implementation....~#end` and will create a file from this. If a single file contains two classes then it will result in for files (two headers and two implementation). Then the original file can be deleted manually or automatically.
I think this above task can be completed in few hours.
Here you can go for save the original file in a folder, just in case you want to rollback.
We have multiple people working on php projects. Is there a way to have netbeans 7.2 call the folder with all the metadata something other than nbproject?
I want all projects I create from existing sources to have something like qwertymk and whenever I create projects or try to load them it will always go to folder named qwertymk instead of nbproject.
Obviously the folder name is hardcoded in several places within Netbeans, but you have options to work around that by placing the nbproject somewhere else, e.g. into a subfoler where it does not get on your nerves. Look at this old thread, specifically at this post. I cannot magically change hardcoded Netbeans stuff for you, but I would be happy if the solution I am pointing you to would satisfy your needs and answer the question.
I just banged my head for a while and figured out a solution, but I want to make sure that I'm doing things right and that I actually know what I'm doing (I'm pretty sure I never know what I'm doing :)
I have two projects that I've been working on, each offering different functionality. I want one project (A) to be able to use the functionality of the other (B). I tried going about it by creating a workspace and putting both projects into it, but I couldn't "see" project B's files from project A (autocomplete after #import did work, but it gave a compiler error). So I tried adding it as a "sub-project" and found the same. I figured this would be easy, but guess not.
What I ended up doing was creating a new project (C) as a "Cocoa Touch Static Library" project, and put my files from Project B into it. I built it.
I then went back to project A and added project C into it as a sub-project.
Then I added the path on the filesystem of project C into the User Header Search Paths setting under Build Settings of project A.
Then I added the .a file from Project C into the Link Binary with Libraries section of Project A.
Then it worked.
But honestly I have no idea what the meaning of a static library is.
Is all this necessary? Or is there an easier way to just integrate two projects (without me having to copy the files from one project to another)?
Thanks in advance!
Jon
You were on the right track with workspaces. What I do is have three projects in the workspace. One with no targets just to hold the generic classes. A second for my iOS target Project. And a third for mac. Keep the original files in the one with no target, then drag the files to the other two projects that creates references, so when you edit one it changes all three.
An iPad project I have been working on has become bloated with a huge number of files. The application is a prototype and we are considering ways to prevent this when we rewrite it.
One of the members of our team suggests dividing all of the components into separate Xcode projects which will be included in a master Xcode project.
Is this a good idea? What are the reasons, if any, to avoid dividing features/components/controls into separate Xcode projects?
You can add a subsidiary project file to a master project file in Xcode. Just choose "Add File" and add it. When Xcode builds the master it will build the subsidiary as well if needed.
I use a similar system. I often break a project into sub projects just so I can focus on and enforce encapsulation. I write the data model first, then add the app delegate, then specific UI elements. I add each project to the next in turn. This also allows me to go back and change things without as much risk of breaking.
Really, a properly designed objective-c app should be easy to decompose into multiple project. Ideally, all the components are so encapsulate that they don't need any others save the data model.
We have put some of the code in its own project, building a framework which we link against at some of the other projects. It's sometimes annoying that you won't see the implementation files of the framework code right away in another project (by cmd+clicking or cmd+shift+D, or whatever you do normally to navigate). Xcode will only show you the header, you'll have to open the other project and find your file there manually. Not a big deal, but if you look up the code often, it will bother you.
A real problem is that you change the scope of some operations. Stuff like "Find in project" will work on a different file set, which might not be what you want sometimes (trying to find where this method is called / key is used in your whole code, or something); well, there remains Finder / find, so it might be okay. Refactoring is not - all the renaming stuff just breaks, as it will change only the code of the current project, but not of projects referencing this one. If you change interfaces often, better avoid splitting up the project.
A good thing is that you will get less conflicts on your .xcodeproj files (if stored in a shared repository) as someone removing a file from project X won't create a conflict with someone else adding a target on project Y, which where previously the same .xcodeproj (not exactly sure this is a conflict case, but there definitely are some).
Now with Xcode4 you can create a workspace and add all your projects there. Only for documentation purpose :)
To view and modify subproject implementation files, you should add the sub projects directly into the main project.
1 step - Drag and drop the .xcode project files to main project.
2 step - Go to main project TARGETS - > Build Phases. Add subproject target in Target Dependencies. You can also add binary files in Link Binary With Libraries.
3 step - Add subproject source path to main projects header search path.
Go to main project - > Build Settings - > Header Search Paths (e.g $(SRCROOT)/../CoconutKit-master/CoconutKit/Sources )
An Xcode project can have any number of build targets within it, and you can arbitrarily group source files into folders. What makes you think that multiple projects are necessary?
I'm working with xcode and I have classes associated with other projects that I want to be included in new projects. I realize that the #import will do the job technically (although what should i do if it's out of the project root folder). But what do I do if I want to include the class "properly" --basically so i can double click and edit out of the main project window where you can see all your files and such.
I guess I'm just looking for the best and/or proper way to include/import (into the project) .h and .m files that I've already created outside of the current project I'm working on. Taking into consideration that I may want to modify the class from the original without subclassing. Hopefully this makes sense.
Thanks,
Nick
Xcode project file organization doesn't reflect the data files on disk. Files can be added to a project from anywhere in the file system. When you add the files, choosing not to copy the files to the current project's directory means that the original files are used. Selecting one of these files in Xcode for editing will alter the original file in that other project. When returning to that other project, Xcode will use the edited files in any further work.
This type of use can be quite handy while working on multiple projects with some shared code. Yet, it can also cause headaches for a versioning system.
Might be worth thinking about how to make the classes into a private framework - then you can import that as another dependency each time. Alternatively you could use a separate version control system location to store the shared classes and just check that out into the project folder.