Mworks MWorks Supporting Components → 0.4.4

Comments and changes to this ticket

• 

  David Cox February 12th, 2010 @ 10:41 PM

  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?

• 

  Christopher Stawarz February 16th, 2010 @ 11:21 AM

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

• 

  David Cox February 16th, 2010 @ 12:11 PM

  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.

• 

  Christopher Stawarz May 7th, 2010 @ 03:12 PM

  • Milestone set to “0.4.4”
  • State changed from “new” to “resolved”
  • Assigned user set to “David Cox”

  Dave implemented this a while back