gistfile1.txt

alunny
hey @pmuellr
pmuellr
alunny yo
pmuellr
so, my basic idea is we have two modes:
pmuellr
1) you maintain your Xcode cruft yourself - and gods help you
pmuellr
2) we maintain it for you - you never edit it yourself, but you can use it for debug etal
alunny
right
pmuellr
for commands like "add plugin", we  regen the Xcode file to add the plugin bits
alunny
I just don't feel 2 is tenable for most of our users
pmuellr
if you're working in mode 1), you're on your own
alunny
simple example
pmuellr
ahhh … but I feel that 1 is not tenable for most of our users!
alunny
user generates new project with our tools
alunny
(presumably with gyp)
alunny
they try to build, but there's a signing issue
pmuellr
(point me to your gyp tools please)
alunny
so they open xcode and select their cert and do a build
alunny
(i'm not using gyp currently - that's the most mature "generate an xcode project" tool I'm aware of)
pmuellr
adding certs should be part of the tooling; how does phonegap build do this?
alunny
phonegap build leans heavily on the `security` utility in OS X
alunny
with not especially reassuring results
alunny
another scenario: user generates app with our tooling
pmuellr
hmmm, does not sound good
alunny
finds some stupid ios issue
alunny
googles it, gets to stack overflow
pmuellr
(now they have two problems!)
alunny
edits their project according to the SO tutorial (all based on the xcode gui(
pmuellr
(now they have three problems!)
alunny
yep
pmuellr
we have big red warning "we will rewrite your f'ing XCode project files by default"
alunny
either we maintain/read the state of the xcodeproj file, or require users to exclusively use our tooling
alunny
which among other things, requires our (unwritten) tooling to be really fucking goof
alunny
*good
pmuellr
the problem I see is the fragility of the XCode file.  We need to be able to "handle" anything anyone throws at us.
pmuellr
And it promotes Xcode as "a valid way to work", which we all know is not true
pmuellr
It's unfortunately needed for debug.  I guess we need to find out what else it's really needed for, like setting certs.
alunny
XCode files aren't that fragile (with the caveat that Apple can change anything at any time)
alunny
they're just arrays, hashes, and literal values with a goofy syntax
pmuellr
I'm sure we can parse the files fine.  I'm not worried about parsing the files.
pmuellr
I'm worried about us trying to make sense of all the possibilities in there - the semantics.  You have a tokenizer; where's the parser and understand-izer?
alunny
we don't need to understand it
alunny
have an xcodeproject
alunny
git commit it
alunny
add a plugin
alunny
run git diff
pmuellr
folders/references/targets/embedded Xcode projects/etc
alunny
with PG Build we were able to add plugins through grep and sed on xcode projects
alunny
as well as change localization settings
alunny
if our tools don't do much, then we don't need to know a whole lot about the project file
pmuellr
we need to make sure certain files/folders exist.  Presumably we dump plugin files in places, and set compile opts.  What if those things are already there?  Or something is conflicting?  Now our users are REALLY screwed.
alunny
it's a hash dude
alunny
if !files["MYPlugin"] files["MyPlugin"] = MyPlugin
pmuellr
I suppose I could become a believer.  I need to see the whole thing running.
alunny
honestly, it's still experimental at this point
alunny
the goal is to get it running with easy plugins (ChildBrowser)
pmuellr
I guess we say "certain things thou shall not do in your Xcode project, like replace the "plugins" directory with one of your own, etc.
alunny
and then more complex ones (there's a company who wants to modify BarcodeScanner for PG Build)
pmuellr
maybe we can recognize when folks have fucked up their Xcode proj, and tell them "sorry, you fucked up.  start over"
alunny
yeah exactly
pmuellr
that seems potentially liveable
alunny
I have a bit of a prejudice against generated code, mainly because I worked on a project that leaned heavily on it a couple years ago
alunny
and it just made a maintainability nightmare
alunny
that said, in restricted use cases the gyp approach is probably a better idea
pmuellr
the only prejudice I have about generated code is when you allow folks to edit generated code, which is basically what you're allowing - THAT has all kinds of problems
alunny
yeah exactly
alunny
but it's difficult in our spot to restrict people from editing that code - it's usually transparent to the user that they're editing a file
alunny
they're just unchecking a checkbox
alunny
opaque, not transparent
pmuellr
So, I think the basic suggestion is, there are certain bits in your Xcode project that belong to us, you must not touch, use command-line tooling to modify.  Everything else, you're on your own.
alunny
yes
alunny
btw, I'd be interested in your thoughts on the plugin manifest format
pmuellr
I assume we will offer to generate an initial Xcode project for folks?  I'd actually prefer that over the template.  The template story for Xcode is soooooo horrible.
pmuellr
yes, that's another thing I want to see!
alunny
https://github.com/alunny/phonegap-plugins/blob/crossplatform/CrossPlatform/ChildBrowser/plugin.xml (prototype)
alunny
yeah I think we should be generating an xcodeproj with the www directory included
alunny
that's still a bit embarassing
pmuellr
yes and yes
alunny
re the manifest
alunny
it's essentially encoding README.md in a format software can understand
alunny
"move some files here, edit some config files"
pmuellr
plugin file: too many attributes; move attributes to text
pmuellr
OMG - namespaced attributes.  KILL KILL KILL
pmuellr
well, maybe that's just for android, not your fault :-)
alunny
yeah, it's an xml literal with an xpath selector in the attribute
alunny
since we can't get away from xml literals, I really don't want to use JSON
pmuellr
JSON bad; YAML maybe ok, CSON (CoffeeScript Object Notation) perhaps; XML is fine, as long as it's not insane