From: Paul Rohr (paul@abisource.com)
Date: Tue Apr 30 2002 - 12:59:39 EDT
At 09:32 AM 4/30/02 +0100, F J Franklin wrote:
>> However, if it turns out that some (or all) plugins *do* belong in the
abi/*
>> tree, please segregate them appropriately:
>>
>> abi/af/xap/plugins/* ... useful for multiple apps
>> abi/wp/plugins/* ... just for AbiWord
>
>Hub suggested, and I agree with him, putting them in abi/plugins.
>
>I suggest keeping the build system separate, since not everyone will have
>all the dependencies.
>
>I'm biased, but I quite like the current build system. Individual plugins
>should still have
>[tools|wp/impexp[/graphics]|scripts|...]/<plugin>/[xp|unix|win|...]/
>subdirs as necessary.
OK. Just to make sure we have the entire taxonomy to choose from, here are
some choices:
1. totally separate plugins tree
---------------------------------
What we have now. Evidently some folks don't like this and want to
eliminate it. I haven't heard why, so it's hard to assess the tradeoffs.
2. abi/plugins/*
-----------------
If people really want to do this, then please follow Frank's suggestion
above and replicate the fanout of the main tree. (I suspect that keeping
the fanouts consistent could become a maintenance, but who knows.)
3. abi/*/plugins/*
-------------------
The medium fanout I proposed. The main goal was to separate xap from ap.
Perhaps a finer-grained distinction is worthwhile though (via #2 or #4). I
have to admit that I haven't been keeping track of plugins, which seem to be
sprouting up in all sorts of flavors.
4. plugins as leaf nodes
-------------------------
I alluded to something like this in my note as well. We currently build
most of our root-level nodes into libraries which then get statically linked
into the binary. For example, the current diving make system supports the
following:
TARGETS= $(OBJS)
TARGETS= $(LIBRARY)
TARGETS= $(PROGRAM)
With clever enough makefile/autoconf hacking, we could theoretically just
introduce another category of build targets:
TARGETS= $(PLUGIN)
Thus, some leaf nodes would build static libraries, and others would build
one or more plugins. If done right, this would allow us to concentrate the
platform-specific mechanisms for plugin-building in a single place, where
they could be easily shared by new plugins.
5. combination of 1 and 4
--------------------------
I still think we want to show people how to build standalone plugins that
aren't part of our source distribution. So even if we do build some plugins
of our own (say, via #4), it'd be helpful for us to also maintain at least a
small tree which shows how to invoke the same magic from outside the tree
(via #1).
Paul
This archive was generated by hypermail 2.1.4 : Tue Apr 30 2002 - 13:00:34 EDT