Greg Hurrell [Sun, 18 May 2014 19:54:54 +0000 (12:54 -0700)]
Disable GC
This setting is actually coming from buildtools, but I don't have
network connectivity at the moment, so I can't upgrade the submodule.
Applying a local override for now.
Wincent Colaiuta [Sat, 29 Aug 2009 15:25:25 +0000 (17:25 +0200)]
distro.sh: distribute package file without zip wrapper
I've now configured the web servers (both nginx and Apache) to serve
".pkg" files with a MIME type of "application/octet-stream" instead of
the default "text/plain". This means that it is no longer necessary to
wrap them up inside zip archives to prevent them from being
inappropriately displayed in the user's browser window rather than
downloaded to disk.
So, drop the zip wrapper and instead just give the package a unique
name. Flat packages are compressed in any case, so the download size
should be basically the same, give or take a few bytes.
This commit is the equivalent of the change made in 17fb9e0 in Wincent
Icon Utility.
Wincent Colaiuta [Sat, 29 Aug 2009 11:23:36 +0000 (13:23 +0200)]
distro.sh: include submodules in source archive
Not the prettiest of solutions but it basically does the right thing:
1. Use "git archive" to produce the standard tar archive of the
repository
2. Use "git ls-tree", combined with "grep", to iterate over all
submodules at the top level of the repo; at present this just
means the "buildtools" submodule
a. Create a temporary directory for each submodule
b. Use "git archive" and "tar" to get a copy of the submodule
source in the temporary directory
c. Add the submodule source to the main tar archive
6. After iterating over all submodules, use "bzip2" to compress the
archive.
By design this is not recursive, nor do I anticipate any need for it to
be so. When/if "git archive" gets built-in submodule support this part
of the script can be considerably simplified.
Wincent Colaiuta [Mon, 24 Dec 2007 15:08:24 +0000 (16:08 +0100)]
Support recursive substitution
In updating my apps to match the latest documentation in Apple's
"Property List Key Reference" I noticed that it would be useful to be
able to do recursive substitution when using the --info and --strings
switches; that is, have one key refer to the value of another key
in an InfoPlist.strings file rather than one in the Info.plist.
This commit therefore gets rid of the simplistic find-and-replace
substitution that was previously implemented and replaces it with a
proper recursive substitution mechanism that allows keys in a strings
file to refer to other keys in the same file, using multiple levels of
recursion if need be, and finally falling back to look-up in the
Info.plist file.
The algorithm is smart enough to detect direct and indirect infinite
recursion (self-referential subsitutions), allow repeated substitutions,
and bail in the event that no suitable substitution can be found.
Wincent Colaiuta [Mon, 24 Dec 2007 13:51:47 +0000 (14:51 +0100)]
Warn about C99 comments
Although the scanner knows how to recognize both C99 (single-line,
Objective-C-style comments) and traditional C commnets (multi-line
comments) it is almost certainly an error for the former to be present
in a plist or strings file, so issue a warning if found.
Wincent Colaiuta [Sun, 23 Dec 2007 18:34:14 +0000 (19:34 +0100)]
Use double-hyphens for all switches
The NSUserDefaults standard for command-line switches uses only a single
hyphen, which is a little unorthodox. Use more conventional double
hyphens instead by inserting an additional hyphen in the default names.
Wincent Colaiuta [Sat, 22 Dec 2007 20:55:59 +0000 (21:55 +0100)]
Add specs for -combine functionality
And based on usability assessment running the specs tweak the warning
issued for duplicate keys to be a little more helpful (ie. explicitly
mention that the same key was found in both files and that the value
from the second file will take precedence).
Wincent Colaiuta [Sat, 22 Dec 2007 20:37:51 +0000 (21:37 +0100)]
Add checks for duplicate keys within the same file
Emit error messages during parsing if duplicate keys found. This is a
serious-enough problem to warrant issuing an error rather than a mere
warning, but we continue processing anyway.
Wincent Colaiuta [Sat, 22 Dec 2007 20:30:36 +0000 (21:30 +0100)]
Favor member: over containsObject:
The looser check done by member: (using isEqual:) is more appropriate
here than the one done by containsObject: (an identity comparison done
using pointer equality, I believe).
Wincent Colaiuta [Sat, 22 Dec 2007 19:38:03 +0000 (20:38 +0100)]
Try multiple encodings in -info/-strings code path
Although we don't strictly need to parse the input file passed in using
the -strings switch (as we're just doing a simple find and replace)
parse it anyway because in this way we can hopefully get the encoding
right on files which don't have BOMs.
Wincent Colaiuta [Sat, 22 Dec 2007 19:22:23 +0000 (20:22 +0100)]
Fix pending tests by using fallback encodings
Instead of using the deprecated NSString stringWithContentsOfFile:
method (not sure why no deprecation warnings were being issued) instead
use stringWithContentsOfFile:encoding:error:. The problem with the
former is that any strings file without a BOM was being interpreted
using the normal C string encoding, which was incorrect and would in
turn cause parsing to fail.
In this way we can explicitly try NSUTF16StringEncoding (should work
for any file that has a BOM) and then fall back to
NSUTF16LittleEndianStringEncoding and NSUTF16BigEndianStringEncoding if
parsing fails.
Wincent Colaiuta [Sat, 22 Dec 2007 18:22:49 +0000 (19:22 +0100)]
Work around CFStringCreateExternalRepresentation() bug
This commit adds some specs to test the operation of the -encode switch
and in so doing has uncovered what looks to be a bug in the
CFStringCreateExternalRepresentation() function.
The docs suggest that a BOM should be added to the beginning of the
string, but in my testing this is not the case.
The workaround is to manually add the BOM, while double-checking to
make sure that the system doesn't add one (just in case the behaviour of
the system changes in the future).
Wincent Colaiuta [Sat, 22 Dec 2007 16:01:35 +0000 (17:01 +0100)]
Allow explicit override of output encoding
This allows wincent-strings-util to be used as a general "clean up" tool
for localizations. For example, a localization might be completed but
have excess whitespace and be encoded with a different endianness (ie.
the original version is sent to the localizer as little-endian but the
localizer uses an editor which saves it in big-endian encoding).
To make performing diffs easier we can use wincent-strings-util to
normalize these non-significant differences, hopefully making the task
of integrating changes much easier.
Wincent Colaiuta [Sat, 22 Dec 2007 14:59:48 +0000 (15:59 +0100)]
Run just-built copy by default
When run from inside an Xcode shell script phase the TARGET_BUILD_DIR
environment variable enables us to find the just-built copy for testing
purposes. The same effect can be achieved by manually exporting the
environment variable and running the specs by hand from the command
line.
When the environment variable is not set, fall back to just running
whatever copy of wincent-strings-util happens to be found first in the
PATH.
Wincent Colaiuta [Fri, 21 Dec 2007 18:38:47 +0000 (19:38 +0100)]
Initial specs
This is an initial batch of specs written using RSpec. Seeing as this is
such a simple tool there doesn't seem to be much sense in doing internal
testing at the Objective-C level; instead just run the tool itself and
make sure it does what it's supposed to do. RSpec is used despite the
fact that wincent-strings-util has absolutely no Ruby in it, simply
because it's a nice framework for doing this kind of thing.
Wincent Colaiuta [Fri, 21 Dec 2007 15:28:28 +0000 (16:28 +0100)]
Make duplicate keys a warning rather than an error
Instead of disallowing duplicate keys during a combine operation, issue
a warning and allow the "target" version to take precedence.
This facilitates a common workflow wherein a localization is incomplete
and its strings file contains a number of key/value pairs that are
unlocalized. In this case those pairs will be extracted with extract()
and the partial strings file that results can be localized. When it
comes time to integrate the partial file, it is necessary to allow
those new strings to override the existing, unlocalized ones in the
previous version of the localizations' string file.
Wincent Colaiuta [Fri, 21 Dec 2007 15:07:09 +0000 (16:07 +0100)]
Hook up new combine() and extract() functions
These two functions can be used to help with incremental localization.
The extract() function looks at a base strings file (in the development
language) and compares it with a target strings file (in the target
langauge). All strings which are new (not present in the target) or
untranslated (present in the target but with the same value as in the
base) are extracted. The output can then be sent to translators for
translation.
The combine() function takes a partial strings file (of the kind
produced by the extract() function) and integrates it with an existing
file using a simple additive algorithm (not a merge). It is considered
an error if there is any overlap in the keys in the two files.
Wincent Colaiuta [Fri, 21 Dec 2007 14:40:54 +0000 (15:40 +0100)]
Refactoring and new functions
This is part of a major clean-up to make way for some new functionality.
The NSScanner category has been split off into a separate file, and a
simple wrapper class has been added so as to eliminate the error-prone
and tedious use of an NSDictionary to model an "entry".
In many places the code has been touched up for better readability.
The functions for handling the new options are in place but not
hooked up yet.
Set up installer package (PackageMaker document, installer window background
PDF, GPL version 3 license in RTF format) and accompanying Shell Script build
phase.
Rather than just letting the autorelease pool leak at the end of execution do
the right thing and drain it first. There's no real need for it in this case
but it's a general good practice so I should get into the habit of doing it.
The auto-indentation bug discovered in the Xcode 2 series (<rdar://problem/4450544>) no longer appears to be a problem in Xcode 3, so remove the workaround.
Rather than using a custom prefix header use the default prefix header for Foundation tools (inherited via build setting from Wincent Build Tools configuration).