You can clone with
No one assigned
From @iamleeg on twitter:
“I think there's value in having a DSL for generating Xcode projects. Probably more SCM-friendly than the native file.”
@madrobby suggested that we could have an opinionated tool which manages the project by just reflecting the groups/files as they are on disk. There can optionally be a ‘Projectfile’ with a “cute Ruby-based DSL” to override these defaults and probably also to configure build settings.
That sounds good to me. One of the biggest causes of merge conflict in Xcode projects is two different developers adding (different) files to the same group: you don't get that in Eclipse because it treats the file system as its data source.
This sounds like an excellent idea. Count me in (as soon as I get some time to actually work!).
I've been working on and off (I got married earlier this month, so more off than on) on a DSL a la Gemfile, Guardfile, etc. I've got defining the folder structure based off of the filesystem (and optionally manually defining any additional groups/files you want) looking pretty good. The DSL essentially looks like:
project :test, :use_filesystem => true, :exclude => 'some/nonsource/dir' do
# let's manually define some additional groups
# notice that group2 is nested inside of group1
group :group1 do
group :group2 do
# include some more files later on if you want to
group :group1 do
group :group2 do
I have been struggling with how to address targets; if anybody has any ideas on a terse way of defining this stuff let me know. In my experience, most people end up including a large majority of their codebase in all targets, so I'd propose something like:
project :testProject do
target :app, :test do
compile '/some/random/file.m', flags => NO_ARC
# some files only go in one of the targets
The problem is that there are a lot of things that are missing in the above target DSL, namely all of the fun of build phases, defining target dependencies. If anybody has a "proposal" on a DRY, 95% case for dealing with targets, let me know. Also, I hadn't yet posted my work, as it is still very 'proof-of-concept', but I'd be willing to put it up on Github if anybody is interested in working on it.
@jaykz52 That’s looking promising!
I would personally focus on just the file management aspect first and release that so people can start giving feedback on it before building the target code on top of it.
Having said that, I think that passing ‘groups’ (with a recursive option) to compile would be very helpful. This would add all the files in the group (and child groups) to the targets source build phase.
Regarding the target definition, I think that if these files get a bit larger defining multiple targets like so target :app, :test might become confusing when you’re looking at the target :test block. I.e. when you look at just the target :test block, you can't tell it inherits settings from another block. I would propose something like:
target :app, :test
target :test, :based_on => :app, :depends_on => :dep_target do
Also, I think it’s very important that people can still get at the underlying objects. For instance, you could yield the PBXNativeTarget to the block if it has a parameter. The same goes for things like build phases etc. This way people can theoretically make anything work, even if that's not covered in the DSL (yet).
I don’t know if I will have time to work on it soon, but I always love to browse through source code :)
Other DSL solutions (JSON type) by Google - https://code.google.com/p/gyp/
Did you know about this tool https://github.com/rayh/xcoder ?
No, interesting tool!
This is a really interesting idea! I started work on a tool (think Rails generator) for Xcode projects. I haven't visited it in awhile because automating a useful Xcode template was taking significantly longer than I had anticipated. With a good DSL for Xcode projects, we could replace the old style templates and build out some robust generators that also configured your Gemfile, Podfile, default pods (testing, networking, etc.) and configured a useful Xcode project.