I've just caught up with the followup traffic on the initial post
and would like to add a few thoughts.
1) Please do not attempt to cut-n-paste the library and rip out the
glib depend. This is not as simple as it was with libole2, we
do actually use gobject now. I've specificly tried to respect
the needs of the abi-dev team when I wrote the library. The goal
is to provide a _shared_ library for our projects to put common
functionality. That is not going to happen if you fork it.
2) GLib has been ported to win32 and most other platforms. You
need not depend on it publicly, but it makes life much easier for
those of us writing in C. There is of course an added cost to
you in requiring yet another depend. Hopefully that should be
more than offset by the added functionality. When the zip file
support lands (hopefully in the next few days) you will actually
be able to avoid a depend on zipios++ or zzlib.
3) Build system pain. This is always an irritation. I had not
though about this. There are lots of potential solutions.
- Have the abi-make people add the appropriate gunk to libgsf
and force libgsf to depend on abiword on the platforms you
support
- Put the core of the abi-build stuff into libgsf and have
that used by abiword and gnumeric
The latter is more work but would help to pull the projects
together. Gnumeric is close to only depending on libs that are
available under win32. Having a build system in place would be
helpful.
4) libxml2 depends. Yes, this could currently be removed. Those
are just convenience routines. My longer term goal will be to
move many of the convenience routines here from gnumeric.
- load/store colours
- DOM tree child by name
- SAX state nodes and support
...
All the useful little tidbits we've accumulated. It would be
nice to share them.
5) Have any of you looked at the api ? I'm specificly interested in
the C++ perspective here. Do you folk use iostreams as your
i/o abstraction ? Is the interface rich enough to allow you to
do what you need ?
