From: Kenneth J. Davis (jeremyd@computer.org)
Date: Mon Nov 03 2003 - 15:52:50 EST
On Mon, 03 Nov 2003 19:21:39 +0100 Marc Maurer <j.m.maurer@student.utwente.nl> wrote:
MM> Lets jump right to the actual content part:
MM>
MM> Our current source tree layout is getting insanely hard
MM> for people (possible new developers) to grasp. Furtermore
MM> our build and packaging systems are overly compilicated,
MM> since important things like plugins and help documentation
MM> resides outside the main abi module.
MM>
I think our tree is well designed to make it easier for new
developers to determine where to look (as long as new commits
continue to follow the original tree layout guides). Sure
we could use some clean up and refactoring (seeing if there
is any duplicated code to move to xp or application specific
code that can be moved to application general (application
framework layer). I find having plugins and docs outside
the tree as simplifying, not complicating.
MM> I want to propose some changes to our current tree layout and
MM> present an idea on how bootstrap AbiShow (that cria thingy that
MM> did not came of the ground) within the current (or new) tree
MM> layout.
MM>
MM>
MM> Proposed Tree Changes:
MM>
MM> General Cleanup
MM> ===============
MM>
MM> 1) Move the abiword-docs module into ./abi/docs
what benifit does this give us?
- it makes cvs update in abi slower, after all the docs are
not updated that often
- docs are only used as a step during package building
(at least with diving make build)
- if you are going to move them, wouldn't ./abi/docs/wp
be the better choice for most of them?
MM> 2) Create ./abi/projects and move IDE projects to it, ie.:
MM> ./abi/projects/msvc
MM> ./abi/projects/anjuta
MM> ./abi/projects/...
sure, but as not all developers require all IDE projects,
it is nicer having them in their own module (as MSVC project
currently is). I think it is better either for them to
all be in their own module or create a new module ide or
so to house them.
MM> 3) Move the abiword-plugins module into ./abi/src/plugins/wp and
MM> compile them by default *). Add the configure switches that
MM> are currently present in the abiword-plugins module to abi's
MM> configure, so people who don't want plugins can disable
MM> building them.
MM>
MM> This also means shipping them by default in _1_ package. Feedback
MM> like
MM> http://gnomedesktop.org/comments.php?op=Reply&pid=19257&sid=1426&mode=n
MM> ested&order=0&thold=-1
MM> means we are not serving our users the best way we can. IMO, users
MM> prefer having most functionality by default any day over a download
MM> package that is as small as possible. They just want it
MM> "To Work", something we cannot say at all giving our current
MM> plugin distribution method.
MM>
MM> Besides, quite a lot of users don't even _know_ that plugins
MM> exists for some particular piece of functionality. That's not
MM> their fault, that's our fault.
There are two issues here,
Development - plugins should stay outside of ./abi or they should
be added back to the main binary.
- a plugin should NOT rely on the internals of abiword
in any way, but on a cleanly exposed API that we can
at least try to make as a stable ABI between minor
releases (e.g. 2.0.1 plugins in theory should work
with a 2.0.2 release, but not necessary with a
2.2.0 release).
Placing the plugins within the ./abi tree will only
further encourage the use of internals and not a clean
separation.
- plugins have extra dependencies, adding plugins to the
default build will require the build process to guess
if these are available and conditionaly compile only
plugins whose dependencies are found or cause a build
failure; presently using diving make that requires
manaully editing the Makefiles before building
- I'm working on getting the Windows installer to
automatically handle when a plugin is not built, and
adjusting the Makefiles to assume libraries are peers,
which works ok on Windows (which has no standard location,
and easier than asking users/devs to update their compilers
global include/lib paths, but not so good for other
platforms where there are standard locations).
- not everyone wants or needs all the plugins, so having
them in abi wastefully adds to its download size and
cvs update time
End Users
- As a modem user, I like the split into smaller packages,
but for higher bandwidth internet access, yes a single
package with all our plugins is simpler. As for user's
not aware of plugins, I think a big change to help would
be for plugins to be directly mentioned on the download
section next to the main setup and not in a separate link
Make it easier for users to know they exist, as right now
its really easy to overlook them, especially if don't
know what a plugin is or that they exist.
- I'm working on integrating the Windows plugin installers
into the main installer script (hence the past email about
switching the default to NSIS v2), but I still think we
should continue to provide a setup without the plugins.
- How about dictionaries? why not include them as well?
MM>
MM> *) Plugins for AbiShow (see below) can go into ./abi/src/plugins/show.
They should be split into plugins/<app> and a plugins/general
where general is for plugins that don't rely on any application specific
data (except maybe where to put in the menu) and can be used by all
applications, e.g. most of the ones in tools, but yes placing plugins
into an application specific subdirectory does sound like a good idea,
though I don't see the justification for moving them into ./abi
MM>
MM> Making room for AbiShow
MM> =======================
MM> (Only to be done when developers show interest)
MM>
MM> 1) Add an ./abi/src/show/ directory for the AbiShow application
MM> The layout of this dir will mirror the structure ./abi/src/wp, ie:
MM> ./abi/src/show/
MM> ./abi/src/show/ap
MM> ./abi/src/show/ap/{xp,unix,win,qnx,mac}
MM> We can start by just 'forking' ./abi/src/wp/ into ./abi/src/show/
MM> 2) Some dialogs currently residing in ./src/wp/ap, like the
MM> FormatTable dialog might be moved to ./src/af/xap/, since
MM> they will be both used by AbiWord and AbiShow.
MM> 3) Fiddle around with the build system to allow the building
MM> of AbiShow
Sounds good.
MM>
MM> Feedback is welcome,
MM> Marc
MM>
MM>
Overall, I don't see moving the separate cvs modules into ./abi
as simplifying anything. As a developer, its easy enough to
get an extra module and nicer to not have to get a module
that you won't use, and as a user it shouldn't matter*.
* I realize on other platforms, users also build, but if they
are building, then they should be intelligent enough to download
two or three files (or cvs co from multiple modules).
But do what you want, as far a plugins go, once I finish getting
this last plugin to build, I'm going to work on updating my
set of AbiCapi plugins (which don't even require the abi tree
to build).
Jeremy Davis
jeremyd@computer.org
This archive was generated by hypermail 2.1.4 : Mon Nov 03 2003 - 15:51:09 EST