i would want to control (some of) the settings of an Xcode project from the command line interface (shell).
are there any tools available for such a use case?
is it possible at all?
or does my request even not make sense at all ? :)
background: for some automation purposes within ContinuousIntegration i'd like to tweak some settings of the project at build time. for this i don't want to have to open the Xcode for making these by some "clickety-click" ... which would hinder the build automation anyway
Related
We use Delphi 10 Seattle. Inside our code we use different compiler directives to produce different exe files, like debug, release version, or versions with different features sets (disable some functions for different customers ...)
Current way of getting the exe files:
change compile options by hand manually typing inside DELPHI IDE ...
compile and copy *.exe to a new location by hand
Any way to get this with one button click (faster approach ...)
Create a build configuration for each of your different feature sets.
Documentation for build configurations is here: Build Configurations Overview. This is the mechanism that the IDE provides for switching between debug and release builds, and there is no reason at all for you not to use the same mechanism to switch between your own configuration sets.
The option set feature allows you to extract certain sets or groups of options into separate files which can then be applied to configurations. You can apply the same option set multiple times, for instance once on top of a base release configuration, and then again on top of a base debug configuration. The build configuration functionality supports inheritance which makes it possible, with a bit of up-front design, to develop a clean hierarchy of configurations.
This configuration functionality is built on top of msbuild which means that you can use the same configurations in your command line builds. In fact, the fact that you mention changing configurations manually in the IDE is a concern. Building your product is not something that should require manual intervention. It is critically important that you address this and arrange that your build process is automated. You can use tools for this, although it is very easy to write your own simple tools that will invoke msbuild for all the configurations that you need to build. Please don't use the IDE to build for release.
As an aside, build configuration is one area of the product where the functionality of RAD Studio surpasses that offered by Visual Studio, in my view.
I am trying build automation for a project developed using legacy language called Team Developer 6. where each file needs to be compiled as an exe. also need to do some filter activity before building exes. there are 300 exes.
this process I could do in simple .Net utility which does the filtering and invokes Team Developer compiler for required files.
Is it possible to put this in to TFS build work flow? what is the best approach for this?
Write an MSBuild project that invokes the necessary commands for the tooling you require and check it in. In the TFS build definition, make use of the default template (at first) and set the MSBuild project file you created as the 'project to build'.
This way you can test your build process locally with MSBuild on the command line, and determine which command line switches you might need. You can set command line switches into the build definition, or if you need some further control you can modify the default template to inject the command line switches directly into the MSBuild activity.
I recommend this way, as then you won't have to create any customized workflow, and can avoid having to go down the road of using custom workflow activities in TFS (which is absolutely supported, but in my opinion a bit difficult to diagnose/debug/maintain/upgrade).
You would ideally want to use an InvokeProcess activity to call an executable which does the filtering and invoking. An alternative but more complex approach would be to create a custom activity, but that requires installation of binaries on the build servers.
The XCode documentation on the concepts of Targets and Projects are helpful, but still I am not certain on the best practices to use in my situation.
I have an existing codebase (used for Windows as well as iOS) in a single SVN repository, which has just been refactored from one single test application into a central library and an application. The idea is more applications will use this central library over time.
An XCode project maps one set of source files to one or more targets, so I could have a single project for my whole codebase and one target for the library and one for each app. However each app will obviously have its own code, so it seems a bit clunky to throw all the source into a single project this way.
Alternatively I could have a workspace with multiple projects, each having a single target. This is much more how I have things set up for the Windows build, where a Visual Studio solution corresponds to the Xcode workspace, and a VC++ project would map neatly against how XCode projects are organised.
But are there 'normal' / expected ways to do things in this kind of situation, some unofficial standards I should try to follow so other developers don't get confused?
Targets nowadays are used to build dependencies and separate builds within a project. You'll see it being used mainly for unit testing. Occasionally, you might have different binaries available to different processors or operating systems, but this is a rarity in today's app store world.
Generally, you'd have one project for each executable. This allows it to be worked on independently and compiled separately without interfering with each other.
You can include projects within projects, which allows you to work on them independently and set up dependencies for them. You can set up a project to build a sub-project and deposit it's executable in a location for your project to link to.
I would say for your situation, make a library project with executable and testing targets. Then include that project in other projects and you can link to or move the files to your other project's location. Here's the gist of how to do it.
I know you don't mention them, but workspaces were basically added to allow you to have multiple projects open in a single window. You can have all your test applications and reference code available without them compiling in the background as well. I find it super handy.
The key difference is that each target is in exactly one project, but one project can be a part of many workspaces. This lets you have projects Lib, AppA, and AppB, and then WorkspaceA = [AppA, Lib] and WorkspaceB = [AppB, Lib], so that developers working on AppA don't have to load stuff related to AppB. As a general recommendation it's a good idea to create projects for things that you might want to share independently.
When I share code between one or more projects (be it Xcode or another IDE), I typically compile the shared parts into a binary and then link it to the code specific projects.
In your setup, something like an Xcode project just to compile a dylib from shared C++ files, and then a main Xcode project that links with this dylib.
It seems that all of the initial Google results for "using subversion with xcode" are actually just tutorials for installing and configuring svn and Xcode, as opposed to actually using the two (i.e. interacting with svn via Xcode's GUI).
Is anyone aware of a good guide that teaches the tricks and pitfalls of working with svn via Xcode's GUI? Something that bridges the gap between the most excellent Version Control with Subversion book and the Xcode IDE (as in pure Xcode GUI without any terminal command use)?
Edit:
We all love our terminal commands, and we all love Eclipse but (and I mean this in the nicest possible way) neither is really the point of the question. I’d prefer to use svn via Xcode’s IDE instead of via terminal just as I prefer (well, for this case) to code in Xcode’s IDE instead of using vim and gcc. Apple engineers spent a good bit of time implementing that SCM menu in Xcode; someone has to have seen a usage guide somewhere.
I used this page as a reference for setting up my XCode projects with SVN. It is a good starting point, but I'll give a short walkthrough of what I did (since the page isn't really all that helpful!).
A couple notes: I'm using XCode 3.1.2 and Subversion 1.4.2. I've heard of problems with using SVN 1.5, but there are ways around that which I wont get into.
First off, I had a repository already set up and created the XCode project afterwards.
In XCode you need to set it up to know about your repository using the SCM tab in the preferences window. Enter:
A Name (this is arbitrary and used for reference with XCode)
The scheme (http or svn)
The host (i.e. svn.example.com)
The path (the exact path to the SVN repository located on the host)
The port (only if it isn't the default)
And a username and password used to access the repository.
The URL will be auto-filled as you enter the other fields. Hit "OK" when all the fields are good and XCode says it can connect.
Then open your project and do a "Get Info" (Round blue icon with an exclamation mark) on the project itself. Under the "General" tab down at the bottom is an option for SCM, select the repository you made in 1 and close the window.
Now open SCM in the menu-bar and go to "Repositories." Hopefully you've built your repository right using branches, trunk, and other directories at the base level because XCode doesn't have support for checking out the root directory. So go one directory at a time down the list and click the "Checkout" button and select a directory to check it out to (I recommend a "Code" or "Source" or "SVN" directory inside your XCode project directory). You cannot checkout multiple directories at once, but you can tell the next directory to checkout before the first has finished and XCode with queue the commands.
Once that is all done go back to your XCode project window and "Add -> Existing Files..." to your project. Select the directory you've checked out the repository to and I recommend using the "Create folder references" option instead of the "Recursively create groups" option because added and removed items will be automatically reflected in a Folder Reference but not in a Group.
Now you've imported your SVN repository into an XCode project. From here any time you make a change, simply Right-Click (Control-Click if you only have 1 button) in the file and at the bottom of the context menu are the SCM options for comparing, committing, updating, and discarding (reverting) the file. You can also use the SCM menu in the menubar for file or project-wide updates/commits/reverts.
I second the comment by the_mandrill, SVN support from within XCode is very limited, especially if you're used to Eclipse.
I also don't understand why everyone seems to need visual clients. I keep a terminal window open on my project directory and I have no problems interacting with SVN from the command line.
I know this is not quite what you asked, but I wouldn't rely much on the use of SVN from Xcode as what you can do with it is very limited. It's useful for being able to do a diff or annotate direct from the IDE but not a great deal else. I don't think it's any substitute for using a separate standalone client such as SmartSVN or Versions.
You also have to jump through a number of hoops to get Xcode to work with SVN version 1.5 onwards, so that's something to be aware of before installing a standalone client. If in doubt, check out a sandbox first.
Here is one of the best tutorials to configure subversion in XCode - http://iphonedevelopment.blogspot.com/2009/03/version-control-is-your-friend.html
It also teaches even to create repository in local MAC.
if you want to work with svn through a gui interface then i suggest you use eclipse + subclipse plugin (which have more features and much more reliable and easy than svn on xcode)..
you will work in xcode as normal but you will use eclipse only as an svn client (by creating a general project in eclipse and make it points to your xcode project directory )
and here is a tutorial of how to install subclipse
A lot of people have problems using the build in svn client, especially to get a new project into svn and that it works.
I created a straight foreward tutorial on how to do this, along with a very well known pitfall (works for Xcode up till the latest version of xcode incl. Iphone 4 sdk)
http://www.sodeso.nl/?p=599
I myself looked up for some good resources and one of the best I've found is a quite recent video from the WWDC 2012 :
Sign in here if it's not already the case : https://developer.apple.com/videos/wwdc/2012/
Then there is a video called :Session 411 - Source Control Management in Xcode
It explains how to use version control both with GIT and Subversion. It's really nice !
Hope it helps!
As has been mentioned in many other answers, the svn client with Xcode is quite weak (and that is being kind).
Personally, I think that running Eclipse just to get access to a svn client is a bit heavy handed.
I would suggest two answers:
Use a dedicated svn client for the Mac (Versions and Cornerstone are both very good, albeit not free... there are free ones, such as svnX)
If you are not wildly comfortable with the terminal, you can script a couple of the key commands that you want to use and add them to your Xcode user scripts folder, then you can trigger them from a menu item of from a keystroke, just as if you were using the Xcode native client. There's a ton of examples on how to do this available via Google.
I came across these - no idea how well they work, but wanted to add some resources if I could:
http://www.macresearch.org/tutorial-introducing-xcode-30-organizer
http://developer.apple.com/tools/subversionxcode.html
With XCode4 you can perform almost all of your SCM tasks from within the IDE itself, this is a great step forward.
Here is a link to the official guide :
http://developer.apple.com/library/mac/#documentation/ToolsLanguages/Conceptual/Xcode4UserGuide/SCM/SCM.html#//apple_ref/doc/uid/TP40010215-CH7-SW26
Unfortunately you still have to use the Terminal command line to add a new project to SCM, this is also clearly documented in the link above.
What it does not tell you is that you also need to manually add ignore instructions to your SCM configuration otherwise you are going to end up with user settings and build outputs in your repositories. I am currently figuring out the list and I will update this answer once I have it finalised.
PS :
I know this question is quite old now but I have added this for those of you who arrive here looking for answers like I did.
PPS :
Terminal command line increases probability of human error, takes longer, is more complex and is less transparent to end users. Overall the omission of being able to add projects to SCM from within XCode is poor design, I expected better from Apple who are usually good at simplifying UI. For the command line fans out there you might feel L337 but try managing a team of programmers and being responsible for their code, command line is not your friend.
Does anyone have any experience of using the project config option with the Delphi Compile Action in Finalbuilder 6.
Currently the build server is set up to manually have all the correct search paths, Compiler options etc set directly on the compile action. This avoids changes to the config file breaking the build, and also search paths etc may be different to dev machines. However it can be a pain to change as it needs to be done in FB rather than in the project.
With the new BuildConfig options in Delphi2009 (and support for them in Finalbuilder 6) it
should be possible to keep this config in SCC and make it easier to maintain and update.
Has anyone tried this?
I use a virtual machine to make a stable build environment, and keep all the options in FinalBuilder. This way I know that I can make a one line change and it will be a good build, with no way I can break things by changes on my dev PC. Of course I do have to update the components etc occasionally, but that can be snapshotted and tested more carefully.
So I guess I've not tried the build config, but I don't want to!