Re: Imported io-lib, a Staden library
On Wed, Jul 09, 2008 at 02:12:31PM +0200, Andreas Tille wrote:
> Hmmm, I try to look very naively on the problem now:
>
> Io_lib is a library of file reading and writing code to provide a general
> purpose trace file (and Experiment File) reading interface.
>
> So naively spoken this is a library for input output operations
> which do not necessarily need a GUI. But Tcl/Tk is a GUI tool
> (hmmm, well, I don't like it, but that might be me) and from the
> description this is not part of io_lib - but something else.
Sorry, there's too many mixed threads going on here I think.
The Staden Package as a whole has a dependency on both io_lib and
tcl/tk (amongst other things). Some of the staden tools crash and burn
inside tk functions (indeed the entire stack indicates tcl/tk), but
that may be due to bugs in the Staden code still. I haven't had the
time to track them down, but just observed it runs fine even under
valgrind with the older tcl releases.
So io_lib itself doesn't have any need for GUI nor tcl. Indeed, apart
from the horrid name, it's probably one of the saner components of the
staden package.
James
PS. The Staden Package is infact more complex than described above. It
also has dependencies on some tcl/tk packages which themselves have
dependencies on versions of tcl/tk too. Eg incr widgets which is built
on incr tcl which is built on tcl. Not all of these are supported
now.
It still appears that the most recent incr widgets release is 2002. I
submitted patches to make this code work with some of the newer
released dependencies, but when no new official release arrived (it's
essentially now an unmaintained package) I produced the hideous
Makefile.thirdparty hack to wget the patch and apply it to the source
tree before building.
The official debian solution to such problems is to have pre-build
mechanisms that apply debian local patches to source releases, but I
need a build system that works on all platforms, hence why I use my
own third-party dependency and patch mechanism. I don't see any way
this can ever be avoided ultimately, although it does lead to
unnecessary duplication.
I don't have time to maintain these third party libraries myself so
ultimately I plan to simply rewrite the code that uses them (it's not
a huge amount fortunately), but naturally that's yet another thing on
the ever-growing to do list.
--
James Bonfield (jkb@sanger.ac.uk) | Hora aderat briligi. Nunc et Slythia Tova
| Plurima gyrabant gymbolitare vabo;
A Staden Package developer: | Et Borogovorum mimzebant undique formae,
https://sf.net/projects/staden/ | Momiferique omnes exgrabure Rathi.
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
Reply to: