Buildscripts/plistcompiler.sh

1. Build Scripts Plistcompiler Shows
2. Build Scripts Plistcompiler Show

Build Scripts Plistcompiler Shows

Takes a file (usually with a suffix of.plistsrc) and 'compiles it' using. # the gcc preprocessor. # The best way to use PlistCompiler is to add a custom build rule to.

This file describes the new structure of the building environment of the AlphaX core. Introduction This is the new model designed during the major code reorganization undertaken after the public release of AlphaX 8.0.1 in November 2005. The original code has been completely rearranged, cleaned of all obsolete elements and reorganized in a hopefully more consistent structure. Top hierarchy The top development folder (let's call it AlphaCore) contains:.

the Current folder with the code currently under development. the Extras folder with auxiliary data. the APIs folder with external libraries common to all versions ( MoreFiles, MoreAtsui). possibly other folders corresponding to the different released versions of AlphaX.

So the structure of this top AlphaCore folder looks like this: AlphaCore - APIs - Current - Extras - 8.0.1 - 8.0b16 - 8.0b17d8 The Extras folder and the Current folder are described in the following sections. The Extras folder The Extras subfolder contains auxiliary data not directly necessary for building the core. This is typically where you can maintain and store documentation, help files, script files to assemble distributions, wiki pages, etc. Currently the SVN repository has the following subfolders: - Extras - Help - Logs - Scripts - Tests - Wiki As needed, other folders can be added therein: texmf, Web Site, XML, etc.

The Current folder This is the development folder with source data corresponding to a particular version. This concerns not only Alpha's source files but also the AlphaTcl library, the various Tcl extensions which are stored in the bundle, possibly the Tcl framework, since all these resources do change from one version to the other. Here is the basic layout of this folder followed by a description of its items: Current - AlphaX.xcodeproj - ChangeLog - AlphaPrecomp/ - AlphaSources/ - AlphaResources/ - Libraries/ - Tools/. the AlphaPrecomp folder contains top level headers or prefix files, mainly the headers used to build precompiled headers with CodeWarrior. Since we now all use XCode, it could be removed. the AlphaResources folder contains the resource files:.r,.rsrc,.plist,.plc, etc. It has an Icons subfolder with some image files (.icns,.png, etc.).!!!!

The.rsrc files now store the resources in the data fork, not!!!! In the resource fork. the AlphaSources folder contains the C and C source files together with their corresponding header files. There are several subfolders which group the files according to the category they belong to. AlphaSources - Application - Controls - CVS - Features - Files - Globals - Menus - TclCommands - Text - Utils - Windows.

Build Scripts Plistcompiler Show

the Libraries folder contains the external elements which will also be included in the application's bundle, such as the AlphaTcl library, some Tcl extensions, additional encodings, a private Tcl framework (if necessary). The copy of these elements is handled automatically by Shell Script phases in the XCode project: this is the role of the Extras target in the XCode project. Its organization is like this: - Libraries - AlphaTcl - Examples - Help - Tcl - Tools - Encodings - ISOmacRoman.enc - macRomanISO.enc - PrivateFramework - Tclextensions The AlphaTcl folder contains the usual AlphaTcl library. This is where you should execute the checkouts from SourceForge. The Tclextensions folder currently contains the following extensions: Memchan2.2.1, Mk4tcl, Tcladdressbook1.1, Tclapplescript1.0, Tclresource1.1.1, tclAE2.0, tcllib1.7, tclx8.4, tdom0.8.0, tnc0.3.0, vfs1.3.

Finally the Encodings folder contains additional encoding files (like ISOmacRoman.enc and macRomanISO.enc) which will be added to the Tcl framework (if any). the Tools folder contains multipurpose scripts. Two of them are used by XCode during the build process (to automatically generate some resources or property lists):. the buildalfar.sh script for instance generates a file Alphaalfa.r in AlphaResources containing the Rez definition of the 'ALFA' #0 resource (whose text is used in the splash screen). the plcompile script processes the.plc file in order to produce the Info.plist file and the PkgInfo file; it is a replacement of the CodeWarrior's property list compiler (see the PList Compiler project at SourceForge). a new ChangeLog file has been started.

The previous file has been renamed ChangeLog1998-2004 and is found in / AlphaCore/Extras/Logs/. AlphaX.xcodeproj is the XCode project file.

Under Panther, it is the AlphaX.xcode file instead. The build folder The XCode project executes its tasks in the build folder as usual.

The output is found in either the Deployment or the Development subfolder, depending on the build configuration. The XCode project has two separate targets: the AlphaX target takes care of building the executable and the Extras target of copying the external elements into the bundle. The target named Final is just a wrapper combining the two previous ones. Last updated 2007-01-14 09:08:58.

I would like to include the application version and internal revision, something like 1.0.1 (r1243), in my application's settings bundle. The Root.plist file contains a fragment like this. Type PSTitleValueSpecifier Title Version Key versionpreference DefaultValue VersionValue Values VersionValue Titles VersionValue and I would like to replace the 'VersionValue' string at build time.

I have a script that can extract the version number from my repository, what I need is a way to process (pre-process) the Root.plist file, at build time, and replace the revision number without affecting the source file. There is another solution that can be much simpler than either of the previous answers. Apple bundles a command-line tool called PlistBuddy inside most of its installers, and has included it in Leopard at /usr/libexec/PlistBuddy. Since you want to replace VersionValue, assuming you have the version value extracted into $newVersion, you could use this command: /usr/libexec/PlistBuddy -c 'Set:VersionValue $newVersion' /path/to/Root.plist No need to fiddle with sed or regular expressions, this approach is quite straightforward.

See the for detailed instructions. You can use PlistBuddy to add, remove, or modify any entry in a property list. For example, a friend of mine blogged about using PlistBuddy. Note: If you supply just the path to the plist, PlistBuddy enters interactive mode, so you can issue multiple commands before deciding to save changes. I definitely recommend doing this before plopping it in your build script. My lazy man's solution was to update the version number from my application code. You could have a default (or blank) value in the Root.plist and then, somewhere in your startup code: NSString.version = NSBundle mainBundle infoDictionary objectForKey:@'CFBundleVersion'; NSUserDefaults standardUserDefaults setObject:version forKey:@'versionpreference'; The only catch is that your app would have to be run at least once for the updated version to appear in the settings panel.

You could take the idea further and update, for instance, a counter of how many times your app has been launched, or other interesting bits of information. Using Ben Clayton's plist Add Run script with following snippet after Copy Bundle Resources. Version=$(/usr/libexec/PlistBuddy -c 'Print CFBundleShortVersionString' '$PROJECTDIR/$INFOPLISTFILE') build=$(/usr/libexec/PlistBuddy -c 'Print CFBundleVersion' '$PROJECTDIR/$INFOPLISTFILE') /usr/libexec/PlistBuddy -c 'Set PreferenceSpecifiers:1:DefaultValue $version ($build)' '$CODESIGNINGFOLDERPATH/Settings.bundle/Root.plist' Appending CFBundleVersion in addition of CFBundleShortVersionString. It emit version like this: By writing to $CODESIGNINGFOLDERPATH/Settings.bundle/Root.plist instead of the one in $SRCROOT have some benefits. It dosen't modify files in working copy of repository. You don't need to case path to Settings.bundle in $SRCROOT. The path may vary.

Testing on Xcode 7.3.1. Based on the example, here's the script I'm using to automatically update the settings bundle version number: #!