Wincent Colaiuta [Thu, 11 Nov 2010 18:50:39 +0000 (19:50 +0100)]
Remove redundant clean-up from dependency resoluton algorithm
Being in the "unresolved" set is used to detect circular dependencies.
It really means "already seen but not yet resolved", so if you see the
same plug-in again it means that you're looping.
It is, however, not necessary to remove items from the "unresolved" set
upon resolution, because, by definition, the "unresolved" set will never
be checked for items that are in the "resolved" array. That is, in
pseudo-code:
if (!resolved but seen)
raise
So, if we've added something to "resolved" the "seen" array won't even
be checked, and if it won't be checked for such items then there's no
need to bother removing them.
Wincent Colaiuta [Thu, 11 Nov 2010 18:38:39 +0000 (19:38 +0100)]
Short-circuit dependency resolution for already resolved plug-ins
Our simple algorithm was sometimes inserted already-resolved plug-ins
into the array, because we were applying the resolution algorithm to all
plug-ins.
The latter is a necessary evil, because we can't know beforehand which,
if any, plug-in we should start traversing the dependency graph from in
order to cover the entire graph.
Given that we will sometimes be re-walking the a portion of the graph,
add an explicit short-circuit check to avoid adding already-resolved
plug-ins to the list again.
Wincent Colaiuta [Sun, 7 Nov 2010 18:31:35 +0000 (19:31 +0100)]
Add fusion-bundle-target.xcconfig
Will use this to provide a consistent basis (in terms of build settings)
for all Fusion plug-ins.
At this stage the only setting passes "-undefined dynamic_lookup" to the
linker. This is a double-edged sword:
- it allows us to refer to symbols in Fusion.framework without having
to explicitly link to it at build time; so far, this is just
laziness
- more importantly, it allows us to refer to symbols in other plugins
without having to link to them (and we're lucky to have this
setting, because we couldn't link to another loadable bundle even if
we wanted to)
- this is less work than the alternatives of:
- getting access to classes using NSStringFromClass()
- defining protocols for all the "foreign" objects we wish to
speak with and then doing all interaction by accessing instances
with type "id <SomeProtocol>"
- instead, we can just reference the header file of the plug-in we
wish to speak with and proceed as though we had access to those
classes inside our bundle
- the down side of all this is that it can mask build errors, because
if we make a mistake setting up the build, we won't find out about
it until runtime; this isn't really an impediment though, because
exactly the same kind of error-masking can occur with the
alternative strategies using NSStringFromClass() and protocols
Wincent Colaiuta [Sun, 7 Nov 2010 18:19:42 +0000 (19:19 +0100)]
Make loadAllPlugIns method callable multiple times
We make this method safe to call multiple times by only loading a
plug-in if it is not already loaded, and only instantiating a plug-in if
it is not already instantiated.
It is useful to be able to call this method multiple times in a pure
plug-in context, to facilitate the following pattern:
- "base" plug-in, which boots NSApplication and calls -[NSApplication
run] (and therefore never returns!), and which then continues the
plug-in loading process by calling loadAllPlugIns again (in response
to an NSApplicationDidFinishLaunching notification or similar)
Chosen for its simplicity, given that extreme efficiency is unlikely to
be needed with the anticipated working set sizes (and if it ever does
become an issue, a more efficient algorithm can be investigated).
Note: the blog post in question makes the issue seem more simple than it
really is as it says, "we'll start with node 'A'", which just happens to
be the only node in the graph which will result in the dependencies
being fully resolved. Starting from any other node will result in an
incomplete dependency graph. So, we need to iterate over all nodes,
applying the algorithm to each in turn, to ensure that we get a complete
graph.
Wincent Colaiuta [Sat, 6 Nov 2010 18:51:07 +0000 (19:51 +0100)]
Get a very basic form of plug-in loading up and running
This commit adds:
- a -[WOFPlugInManager loadAllPlugIns] method to bootstrap the loading
process
- a -[WOFPlugIn instantiate] method to instantiate an instance of the
plug-in's principal class after loading
- an instance property that provides access to that object created by
the instantiate method
Wincent Colaiuta [Sat, 6 Nov 2010 18:04:06 +0000 (19:04 +0100)]
Add WOFPlugInProtocol
Doesn't do much interesting stuff yet, but it's a starting point. Note
that the possibility of repeated activation and deactivation is
mentioned in the code comments, but our initial implementation will just
perform once-off activation and we'll worry about implementing
deactivation later.
68b492d Fix typo in comment 50174da Remove files made redundant by @rpath/-rpath 04d9662 Remove another file made irrelevant by @rpath/-rpath b340c54 Update copyright year range d01c90e Drop GCC_SYMBOLS_PRIVATE_EXTERN setting 608b69f Move common settings up into the base xcconfig file cb9f04e Remove ZERO_LINK setting, as it is long since dead f80be60 Another dead-in-the-water build setting aa1acf9 Remove another legacy setting 10827cb Two more legacy settings bite the dust
087faa9 Lay separate build-intermediates folder to rest 40213a8 Add note on why BUILDTOOLS_DIR is set the way it is e9f4081 Drop SHARED_PROJECTS_DIR setting 6f0c519 Annotate some more cryptic build settings 0834296 Remove unnecessary DSTROOT setting e336031 SYMROOT is now ../build rather than ../../build
Wincent Colaiuta [Wed, 3 Nov 2010 20:07:31 +0000 (21:07 +0100)]
Store dependencies array on initializing a plug-in
For now we just blindly store the returned object in a property without
checking its type or content; later on this will probably evolve into an
array of WOFDependency objects.
Wincent Colaiuta [Tue, 2 Nov 2010 22:25:42 +0000 (23:25 +0100)]
Add WOPublic as a submodule
Fusion itself won't incorporate any code or symbols from WOPublic, so as
to allow other projects to be able to use both Fusion and WOPublic
without having to worry about clashes, but it can still make use of
non-symbol content such as macros (in particular, I will shortly be
making a commit that makes use of the WO_EXPORT macro).
Wincent Colaiuta [Mon, 1 Nov 2010 18:05:11 +0000 (19:05 +0100)]
Don't search for plug-ins in "system" domain
The sample code in the Apple documentation specifically excludes the
"system" domain, presumably because it is supposed to be
Apple-controlled and never written to by anyone else.
git.wincent.com / fusion.git / log
