Wincent Colaiuta [Fri, 5 Nov 2010 21:02:13 +0000 (22:02 +0100)]
Drop GCC_SYMBOLS_PRIVATE_EXTERN setting
This always used to work for me with my 32-bit builds, but now that I am
targeting 64-bit it's biting me. Basically, it hides Objective-C classes
now, which means you can't link to frameworks built with this build
setting active.
A couple resources I turned up in my search for info on this:
http://lists.apple.com/archives/xcode-users/2009/Dec/msg00178.html
(post from a guy also surprised by the behavior change in the move
from 32-bit to 64-bit)
http://www.cocoabuilder.com/archive/cocoa/217622-how-to-export-class-while-the-framework-gcc-symbols-private-extern-is-yes.html
(thread which suggests that this might actually be a Clang/LLVM thing
only, as GCC apparently thinks that visibility is "not applicable to
Objective-C classes")
Whatever the case, I'm losing this build setting. It was only there to
make reverse-engineering a tiny bit harder, and I'm much more interested
in openness and things just working, than obfuscation and secrecy
nowadays.
Wincent Colaiuta [Fri, 5 Nov 2010 18:39:50 +0000 (19:39 +0100)]
Use @rpath instead of @exectuable_path
This will allow us to build a single framework for use in a variety of
contexts. Rather than overwriting the install path with
install_name_tool(1), we can just change the setting we pass to the
linker when building the consuming application.
Wincent Colaiuta [Thu, 4 Nov 2010 21:36:49 +0000 (22:36 +0100)]
Set LD_DYLIB_INSTALL_NAME using @executable_path
This should allow applications to locate the framework when they embed
it. In order to install such a framework to /Library/Frameworks/, the
InstallFramework.sh script can be used.
I haven't used it for some time, but I believe the
installed-framework-target.xcconfig file is probably in a broken state
right now; without the INSTALL_PATH and DSTROOT stuff it should be
possible to build a framework suitable for installation using the
default Xcode build setting for LD_DYLIB_INSTALL_NAME.
Wincent Colaiuta [Thu, 4 Nov 2010 18:20:05 +0000 (19:20 +0100)]
SYMROOT is now ../build rather than ../../build
This is a big change but will allow us to intermix complex,
multi-component projects with invidividual component projects.
The comments included in this commit describe the kind of project layout
that is intended to work well with this setting.
Wincent Colaiuta [Wed, 3 Nov 2010 22:52:52 +0000 (23:52 +0100)]
Drop SHARED_PROJECTS_DIR setting
This is not used anywhere at all, and I am moving away from the "shared
projects" approach in favor of more use of Git submodules. That is,
instead of:
project-1 (in SHARED_PROJECTS_DIR)
framework-1 (in SHARED_PROJECTS_DIR)
framework-2 (in SHARED_PROJECTS_DIR)
Wincent Colaiuta [Wed, 3 Nov 2010 22:46:30 +0000 (23:46 +0100)]
Lay separate build-intermediates folder to rest
I'm currently trying to simplify the build folder layout to handle some
new submodule workflows, so this is one way to cut down the number of
moving parts. The OBJROOT folder is actually fairly neat and tidy, so
merging its contents into SYMROOT is not going to clutter things up.
Wincent Colaiuta [Sun, 31 Oct 2010 21:10:51 +0000 (22:10 +0100)]
Target 64-bit architecture only
With this we can make use of new features that are available only in the
"modern" Objective-C runtime. I don't plan on publicly releasing any
products depending on the modern runtime until Mac OS X Lion is
available to the public.
Wincent Colaiuta [Mon, 23 Aug 2010 18:02:01 +0000 (20:02 +0200)]
Help: remove generator line
This just creates noise in the VCS with each Walrus update, given that
the generated files tend not to change at all between versions. In any
case the HTML is not really the place to advertise the templating
engine; that's what blogs and other forums are for.
Wincent Colaiuta [Mon, 23 Aug 2010 12:43:23 +0000 (14:43 +0200)]
Add Rakefile.example
This is an application-level Rakefile (intended to run from SOURCE_ROOT/Rakefile)
that can be used to update the help files. Rake's dependency analysis is used to
ensure that only items which need to be re-compiled or re-filled actually get
updated.
Wincent Colaiuta [Mon, 23 Aug 2010 12:31:52 +0000 (14:31 +0200)]
Remove license header from example templates
The license of buildtools itself shouldn't be propagated into templates
which are created in other projects and based on the examples. The
including project should instead insert its own license, if applicable.
Wincent Colaiuta [Sat, 29 Aug 2009 13:49:33 +0000 (15:49 +0200)]
ReleaseNotes.sh: handle first release
Our "git describe HEAD^" call fails for the first tagged release because
there are no prior tags.
Catch the error and just use the first root commit instead.
This is not the only place where we use "git describe", but it is the
most likely place where problems will crop up in practice (because
usually there is at least _one_ annotated tag in the repo if we are
running this script).
But with the switch we instead produced results like:
"Changes from 2.0 to 2.0"
And we didn't list any changes at all.
Now we list changes since the last annotated tag in that case, bring the
behaviour into line for both cases.
Note that this commit does add one "BUG" comment, because I noticed
while testing that this will break down in repos with no annotated tags
("git describe" bails in such repos). There are probably other issues
too when running the script in repos whose HEAD points to older TAGS (I
suspect it will always just produce release notes for the latest
version), so there is still room for some improvement.
Wincent Colaiuta [Wed, 24 Jun 2009 16:46:47 +0000 (18:46 +0200)]
Change location of BUILDTOOLS_DIR
Make the buildtools Git submodule-friendly by changing the BUILTOOLS_DIR
variable: projects which use the base config file should now expect to
find the buildtools in a subdirectory of the parent project's source
root.
This should make individual projects more robust in the face of changes
to buildtools, because it means that they can pin the version of
buildtools that they use to a specific, "known good" commit.
The developer of a project using buildtools can chose to integrate
upstream changes when he/she wishes, rather than being forced to
integrate and fix any breakage just because upstream happened to move in
the intervening interval.
It should also make it easier to make initial clones of projects using
buildtools because now users can just pull down the parent project
rather than having to worry about performing multiple clones and
ensuring that each repository is in the appropriate relative location.
This is actually quite a large change so at the time of writing I've
split the repository into two branches: this commit is appearing first
on the "master" branch, while the "maint" branch is being left as it was
before.
Fix absolute path bug in UpdateStringsFiles script
The LANGUAGE variable contains an absolute path; add a BASE_LANGUAGE
variable containing only the basename for those occasions where what you
want is actually a relative path.
Wincent Colaiuta [Wed, 23 Jan 2008 15:09:54 +0000 (16:09 +0100)]
Append extra blank lines at end of output
When emitting release notes for a project that is spread out across
multiple repositories we may end up invoking the ReleaseNotes.sh script
several time, successively appending more and more output to the
generated notes.
Add two extra line feeds to make this easier: one because "git log"
doesn't seem to emit one, and another to provide visual separation
between sections.
Wincent Colaiuta [Wed, 23 Jan 2008 15:08:19 +0000 (16:08 +0100)]
Automatically append wildcard to tag prefix
Make life slightly easier for callers by automatically appending the
wildcard (asterisk) to the passed-in tag prefix, thus saving them from
having to do it.
This assumes a convention that tags will following a
"product name-product version" naming pattern.
Wincent Colaiuta [Wed, 23 Jan 2008 14:58:28 +0000 (15:58 +0100)]
Always direct error and diagnostic output to the stderr
Without this it may be harder to diagnose script failures (for example,
in the ReleaseNotes.sh script we normally redirect the output to a file;
in that case any error messages wind up in the file rather than in the
Xcode build window where we want to see them).
Wincent Colaiuta [Wed, 23 Jan 2008 14:02:00 +0000 (15:02 +0100)]
Teach release notes script to take an optional prefix parameter
With this parameter and the help of a convention we can now produce
release notes for projects spread across multiple repositories.
In the "main" project repository we just invoke the script as normal
(without parameters) and it uses "git describe" to find the last tag,
the previous tag, and emit the differences between them.
In the secondary repositories we pass a "tag prefix" which we use to
locate the tags corresponding to the release of the "main" project; in
other words this depends on a convention in which we create tags in
the secondary repositories which have a unique prefix which identifies
the main project.
Wincent Colaiuta [Thu, 27 Dec 2007 14:14:04 +0000 (15:14 +0100)]
Produce longer release notes if --long switch passed
Note also that we just use "git log --pretty=format" rather than piping
through "git shortlog".
There is a strange behavioural discrepancy here with newlines depending
on whether the script is run interactively or via Xcode; work around it
by just echo a blank line rather than trying to pass "\n".
Wincent Colaiuta [Mon, 24 Dec 2007 18:10:23 +0000 (19:10 +0100)]
Modernize UpdateStringsFiles.sh
Make some tweaks to UpdateStringsFiles.sh to make it more generally
suitable. In particular, the ability to specify separate source and
resources folders means that we can use this script in the Synergy
build process now (because the Synergy code base dates back a very
long way now and doesn't follow the standard locations which you
get when you set up a new project).
These changes basically make the UpdateStringsFile.sh script
redundant, so remove it.
I am still not entirely happy with this script -- it is now showing
its age -- despite the fact that it works. In the future will probably
do some more refactoring to clean this up and correctly distribute
responsibilities among this, the UpdateXibs.sh script, and possibly
others.
Wincent Colaiuta [Sun, 23 Dec 2007 20:00:19 +0000 (21:00 +0100)]
Be more verbose
While trying to debug a failure case I noticed that it was possible for
the script to terminate early (due to the "set -e") but for no error
message to be printed to the standard error.
So be more verbose about what's happening, and install an exit trap to
draw attention to an unexpected early exit.
git.wincent.com / buildtools.git / log
