On Tue, 13 Sep 2005, David Berry wrote:
> It *really* would be a good idea to do the de-graphicising of
> kappa/kaplibs on a branch :-) Having just done a cvs update I can't get
> things which depend on kaplibs to build. Is there any chance of
> reverting the trunk back to the kaplibs as of friday?
Should work now. Sorry about that. Flaky networking.
You will need to relink kappa, polpack, kaprh and echomop. Atools should
be fine with the installed libkpg. Kappa may need to be given a hand since
kappa_link_adam is not recreated automatically if kappa_link_adam.in is
updated (issue 'make kappa_link_adam').
Anyway, I've committed a (hopefully uncontroversial) patch to kappa such
that now only ndfpack_mon actually links against the tcl/tk libraries.
It's a step in the right direction at least.
A branch is probably a good idea but I don't think it's a lot of work.
Simply creating a new monolith for the kappa_mon routines that also do
graphics is about 10 minutes work and the actual main work is on the
trunk anyway: making sure that any routines that thought they knew which
monolith those handful of routines were in are updated.
KPG1_ASSET seems to be the only substantive issue unless people can come
up with a better approach to this (and I think KPG1_ASSET is tractable by
cloning it, removing the PLOT support and giving it a new name).
If people do not want me to create a new monolith please let me know and
I'll abandon the whole 64bit-on-OSX kappa thing until apple releases a
proper 64bit OS (I think the kaplibs tweaks are useful). [I may still do a
private hatchet job on kappa for performance testing though]
PS I removed kpg1_gtgrp from atools. It was the same as the kaplibs
version and atools was linking against kaplibs anyway... I also removed
atl1_rm.c and replaced it with a call to PSX_REMOVE. [and the same fix to
kappa/atools - grr]
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|