Create Xcode project DSL #14

Closed
alloy opened this Issue Jun 4, 2012 · 10 comments

Comments

Projects
None yet
7 participants
@alloy
Owner

alloy commented Jun 4, 2012

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.”

@alloy

This comment has been minimized.

Show comment Hide comment
@alloy

alloy Jun 4, 2012

Owner

@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.

Owner

alloy commented Jun 4, 2012

@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.

@iamleeg

This comment has been minimized.

Show comment Hide comment
@iamleeg

iamleeg Jun 5, 2012

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.

iamleeg commented Jun 5, 2012

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.

@goonzoid

This comment has been minimized.

Show comment Hide comment
@goonzoid

goonzoid Jun 10, 2012

Contributor

This sounds like an excellent idea. Count me in (as soon as I get some time to actually work!).

Contributor

goonzoid commented Jun 10, 2012

This sounds like an excellent idea. Count me in (as soon as I get some time to actually work!).

@jaykz52

This comment has been minimized.

Show comment Hide comment
@jaykz52

jaykz52 Jul 5, 2012

Hey guys,

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:

# /some_awesome_ios_project/ProjectFile

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
    inc 'test1.m'
    inc 'test2.m'
    group :group2 do
      inc 'test3.m'
    end
  end

  # include some more files later on if you want to
  group :group1 do
    inc 'test4.m'
    group :group2 do
      inc 'test5.m'
    end
  end
end

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/relative/dir'
    compile '/some/random/file.m', flags => NO_ARC
  end

  # some files only go in one of the targets
  target :test
    compile '/some/test/dir'
  end
end

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 commented Jul 5, 2012

Hey guys,

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:

# /some_awesome_ios_project/ProjectFile

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
    inc 'test1.m'
    inc 'test2.m'
    group :group2 do
      inc 'test3.m'
    end
  end

  # include some more files later on if you want to
  group :group1 do
    inc 'test4.m'
    group :group2 do
      inc 'test5.m'
    end
  end
end

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/relative/dir'
    compile '/some/random/file.m', flags => NO_ARC
  end

  # some files only go in one of the targets
  target :test
    compile '/some/test/dir'
  end
end

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.

@alloy

This comment has been minimized.

Show comment Hide comment
@alloy

alloy Jul 6, 2012

Owner

@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 :test, :based_on => :app, :depends_on => :dep_target do
    # ...
  end

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 :)

Owner

alloy commented Jul 6, 2012

@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 :test, :based_on => :app, :depends_on => :dep_target do
    # ...
  end

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 :)

@xslim

This comment has been minimized.

Show comment Hide comment
@xslim

xslim Feb 26, 2013

Contributor

Other DSL solutions (JSON type) by Google - https://code.google.com/p/gyp/

Contributor

xslim commented Feb 26, 2013

Other DSL solutions (JSON type) by Google - https://code.google.com/p/gyp/

@xslim

This comment has been minimized.

Show comment Hide comment
@xslim

xslim Feb 27, 2013

Contributor

Did you know about this tool https://github.com/rayh/xcoder ?

Contributor

xslim commented Feb 27, 2013

Did you know about this tool https://github.com/rayh/xcoder ?

@fabiopelosin

This comment has been minimized.

Show comment Hide comment
@fabiopelosin

fabiopelosin Mar 9, 2013

Owner

No, interesting tool!

Owner

fabiopelosin commented Mar 9, 2013

No, interesting tool!

@paulpilone

This comment has been minimized.

Show comment Hide comment
@paulpilone

paulpilone Jun 28, 2013

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.

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.

@fabiopelosin fabiopelosin added feature and removed feature labels Mar 27, 2014

@fabiopelosin fabiopelosin changed the title from [Fun idea] Create Xcode project DSL to Create Xcode project DSL Mar 27, 2014

@fabiopelosin

This comment has been minimized.

Show comment Hide comment
@fabiopelosin

fabiopelosin Jul 19, 2014

Owner

Closing as the discussion is pretty old and while this might be a very interesting feature it is outside the current scope of Xcodeproj.

Owner

fabiopelosin commented Jul 19, 2014

Closing as the discussion is pretty old and while this might be a very interesting feature it is outside the current scope of Xcodeproj.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment