Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

Shared Xcode build settings should live in external files

#6

There are many build settings (e.g. install paths, compiler versions) that are duplicated in every MonkeyWorks Xcode project file. We could eliminate this redundancy and simplify the process of changing build settings by moving shared settings to external build configuration files. See http://developer.apple.com/Mac/library/documentation/DeveloperTools... .

Reported by Christopher Stawarz · February 12th, 2010 @ 05:34 PM

State: resolved
Milestone: 0.4.4
Assigned to: David Cox David Cox

Activity

  1. David Cox
    David Cox

    This is a great idea, especially as the number of project files has exploded since the introduction of plugins.

    One question is where they would live. Perhaps the most sensible thing would be to have the external config in git repo by itself, which could then be included as a submodule in the other projects. I think that this is probably superior to the alternative (e.g. the Application Support/MonkeyWorks/Developer, which would lead to a chicken-egg problem, or in any one repo, which require other projects to know where that repo is checked out).

    Any thoughts?

    February 12th, 2010 @ 10:41 PM

  2. Christopher Stawarz
    Christopher Stawarz

    To me, it just seems simpler to put the configs in /Library/Application Support/MonkeyWorks/Developer (maybe in an "Xcode" subdir). That's where we put all the other build dependencies, and it would give users who develop plugins a standard place to look for the config files. I envision an "Xcode" directory in mw_build that contains both the config files and a Makefile or Python script that installs them.

    My (admittedly limited) experience with git submodules is that they're a bit of a pain to set up and use. Plus, if we need to include the same submodule in every MW repo with an Xcode project, then we're back to a situation where we're duplicating the same setup in many different places (although it'd still be an improvement over the current situation).

    February 16th, 2010 @ 11:21 AM

  3. David Cox
    David Cox

    Irrespective of what we decide here, you should give git submodules another try; they're really not very complicated at all. If you have a bad taste in your mouth left over from SVN externals, they really are much better.

    As for the Developer dir, my initial concern with this was that it makes the individual repositories less self-contained, introducing a bit of a chicken-and-egg problem where builds do not (and cannot) stand on their own (e.g. depending on which version of mw is installed we can get different results for all of the builds).

    However, I guess that this is all already true because of the mw_supporting libraries, so it's not a huge deal to me either way. In some ways, this is actually nice, since it could enforce that the build settings match those for the mw_supporting libraries, assuming we've done something sensible when putting together the installer.

    And we can still enforce cross-repository version dependencies at the level of the mw_suite, including the Xcode configs, though we will obviously need to remain diligent about ensuring that these config files are planted freshly when doing a fresh build.

    February 16th, 2010 @ 12:11 PM

  4. Christopher Stawarz
    Christopher Stawarz
    • Milestone set to 0.4.4
    • State changed from new to resolved
    • Assigned user set to David Cox

    Dave implemented this a while back

    May 7th, 2010 @ 03:12 PM

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.