My interpretation is that 'build' is passed as a string, turned into a selector, and then invoked on PBXContainer (which gets unpacked using PBXCoder).
Which means you're really interested in this:
(Note: I'm linking to Github, because it's more convenient for me, but note that the canonical version control system is still Subversion, at
http://svn.gna.org/svn/gnustep).
Based on PBXContainer's implemented methods, you could seemingly call the following methods and have it work: 'build', 'clean', 'install'. Somewhat uselessly, you could (but probably want) also call 'archiveVersion', 'classes', 'objectVersion', 'objects' and 'collectHeaderFileReferences'. Amusingly, you could call 'dealloc', too, but I doubt that would help.
PBXContainer's implementation of 'build' seems to forward this to the 'root object'. Reading an arbitrary .pbxproj grabbed from the Internet, a 'rootObject' will probably be an object of type PBXProject.
Reading -[PBXProject build] method, you can see that the answer to your question is 'no, you cannot filter out which target will be built'.
But because this is a tool (and accompanying framework) that's very easy to follow around, this seems like something that'd be very easy to hack together. I would look into how you can store the 'desired target' in GSXCBuildContext. Then, if this desired target is non-nil, you'd skip every other target when executing -[PBXProject build].
If you choose to do this, and decide to contribute the patch upstream (which means you'd follow existing code style etc), I think we can accept it even without formal copyright assignment (I think the patch might be short enough). That's probably up to Gregory, who authored the tool.
Greg?