• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Build Phase - Run Script - a few questions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Build Phase - Run Script - a few questions


  • Subject: Build Phase - Run Script - a few questions
  • From: Steve Cronin <email@hidden>
  • Date: Sat, 28 Mar 2009 17:51:28 -0500


Folks;

I'm still pretty shaky on XCode as tool (its so darn big and it just won't stand still)

Goal: versioning of some supporting text files that are part of my apps Resources.
The app deploys the initial version of these files
it is possible for the user or data to update these files which live in (~/Library/Application Support/myApp)
In later versions of the app these files might morph.
I want the app to be able to check the 'version' of a deployed text file to determine whether an update should be offered to the user.


Current Strategy:
Add Finder comments to the files. I know its not bulletproof (the user themselves can fiddle these values - not too likely but still possible)
My later apps can then check current installed version of the text files by using 'kMDItemFinderComment' (I have this piece working)


If there is a better strategy I am all ears!

Problem:
During the build of the application the 'Copy Bundle Resources' phase strips off any Finder comments assigned to these text files.


Proposed Solution:
Add a Run Script build phase that reassigns the the Finder comments from the source files.
The applescript to do this in principle is pretty easy.
Is there an alternate way to do this without AppleScript?


Questions:
How can I reliably reference the new objects just handled by the 'Copy Bundle Resources'? (Debug and Release builds both?)
Can I just use /usr/bin/osascript/ as the shell? Or is it more complicated than that?
Is this whole thing a "Bad Idea"™?


Thanks for sharing your thoughts and wisdom,
SteveFolks;

I'm still pretty shaky on XCode as tool (its so darn big and it just won't stand still)

Goal: versioning of some supporting text files that are part of my apps Resources.
The app deploys the initial version of these files
it is possible for the user or data to update these files which live in (~/Library/Application Support/myApp)
In later versions of the app these files might morph.
I want the app to be able to check the 'version' of a deployed text file to determine whether an update should be offered to the user.


Current Strategy:
Add Finder comments to the files. I know its not bulletproof (the user themselves can fiddle these values - not too likely but still possible)
My later apps can then check current installed version of the text files by using 'kMDItemFinderComment' (I have this piece working)


If there is a better strategy I am all ears!

Problem:
During the build of the application the 'Copy Bundle Resources' phase strips off any Finder comments assigned to these text files.


Proposed Solution:
Add a Run Script build phase that reassigns the the Finder comments from the source files.
The applescript to do this in principle is pretty easy.
Is there an alternate way to do this without AppleScript?


Questions:
How can I reliably reference the new objects just handled by the 'Copy Bundle Resources'? (Debug and Release builds both?)
Can I just use /usr/bin/osascript/ as the shell? Or is it more complicated than that?
Is this whole thing a "Bad Idea"™?


Thanks for sharing your thoughts and wisdom,
Steve
_______________________________________________
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


  • Prev by Date: gcc output of memory related problems to command window
  • Next by Date: Question about IB and debugging
  • Previous by thread: gcc output of memory related problems to command window
  • Next by thread: Question about IB and debugging
  • Index(es):
    • Date
    • Thread