Re: project structure for two-stage core data build
Re: project structure for two-stage core data build
- Subject: Re: project structure for two-stage core data build
- From: James Bucanek <email@hidden>
- Date: Thu, 28 Jan 2010 09:28:46 -0700
Matt,
There are a couple of ways of doing this. You already have a
target to build your application, so you follow these steps:
1) Create a script target for your "Final" application.
2) Create a script target to build your database. Let's call it
"DB Compile"
In the DB Compile target, write a script that takes the text
form of your database and produces the compiled form by running
your application. Make this target dependent on your existing
application target.
In the "Final" script target, write a script (or add copy
phases) that simply copy the entire application product bundle
produced by your existing application target, and then copy the
compiled database from the DB Compile target into that bundle.
Make this target dependent on both your application target and
the DB Compile target. (This assumes that your application
automatically quits after compiling the txt file--if not, you'll
need to code that.)
Now when you build the Final target, it first builds the
application, runs the application to produce the compiled
database, copies the application to a new bundle and inserts the
compiled database intot its resources.
This should work, but personally, I won't set up my build this
way. It's awkward for a number of reasons (hard to debug,
slow,...). So here are some other suggestions.
If I assume that your application never reads the text version
of your database and it never (normally) uses the code to
compile the text version, I'd rip that code out of the
application and create a Core Foundation command-line tool that
converts the text file into the database. You've now a
stand-alone DB compiler.
You can now create a script target that runs your tool to
produce the compiled database. Now make your application target
dependent on the DB Compile target and add a resource copy phase
to insert the compile DB into your final application bundle.
But the cleanest solution would be to add a custom build rule to
your application target that uses your DB compiler tool to
transforms the txt file into the SQLite database during the
compile phase of the target. Now your txt file simply becomes
another source file to compile during the application's build phase.
Enjoy,
James
Matt Neuburg <mailto:email@hidden> wrote (Wednesday, January
27, 2010 10:11 AM -0800):
Here's my problem. Tell me how to structure my project to handle it. The
issue, in a nutshell, is that my data starts life as text files but in my
shipping app the data is expressed as a Sqlite database. So there are two
steps when I build my app:
Step 1:
I have a bunch of text files. I read them and parse them into a Core Data
in-memory store. Then I switch the store to a Sqlite store and save out the
database.
Step 2:
I build my real app. It contains the database - not the text files - and
uses pure normal Core Data Sqlite store procedures.
The way that I originally solved this problem works but isn't easily
maintainable. I didn't quite know where I was heading with this, so I didn't
plan very cleverly. I have just one target. What I did involved building and
running my single target twice, with adjustments to the code and the target
structure in between.
So, the first time, the text files were included in the target; I build and
run the app, the app starts up, reads the text files from inside its own
bundle, saves the Sqlite database, and quits. Then I remove the text files
from the target, add the database to the target, comment out a bunch of
code, uncomment some other code, and now we've got the target for the "real"
app that I ship.
So my real app depends upon a sort of "pre-app" that must not only be built
but must actually be *executed* in order to generate the database as an
intermediate product. How should I express this entire two-step dance as a
single build operation? Thx - m.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden