On Mon, 4 Oct 2004, David Berry wrote:
> > + New -notk option the _link scripts to enable applications
> > to link against kaplibs without bringing in Tcl/tk dependencies
> > [most applications except ndfpack will want to use this option
> > - a good case could be made for moving kpg1_ast.c out of
> > kaplibs and into libndfpack since it is hard-wired to load
> > $KAPPA_DIR/tkast.tcl. Doesn't sound very generic. If it can
> > be moved into libndfpack that would make things much simpler
> > and the -notk option could be removed.]
>
> Seems fair enough. I've moved kaplibs/kpg1_tkast.c to kapsub/kps1_tkast.c
> and changed to kaplibs and kappa linking scripts, etc, accordingly.
>
but that isn't ideal because it still leaves both KAPPA_MON and
KAPVIEW_MON with a tcl/tk dependency that they don't care about.
> > + The help stuff has been removed. SHL now implements this functionality.
>
> Had to change shl to install SHL_HLPCMD as a public include file because
> it is needed by kappa.
>
but SHL_HLPCMD is a common block and so can not be installed publically.
No common blocks can be public includes when we use shared libraries.
That's the whole point. It seems that you are wanting a pager function
that keeps track of how many lines have been sent to the screen. I didn't
really want to make SHL_PTHLPO a public function but now I clearly have to
think about it (and this would require a SHL_INIT routine to allow people
to configure the private common block).
I also forgot to mention that KPG_AST is no longer installed. I wrote a
kpg1_astcmn.f for common block access.
> > A final idea may be to add -aif to the link script to allow those
> > residual aif users to use aif without hitting problems and other
> > dependencies. It's almost worth allowing kaplibs/aif to install a simple
> > aif_link[_adam] script.
>
> I've forgotten what the issue is here. Why is aif a problem?
>
Because AIF has 4 routines in it and people who are only using those 4
routines don't want the whole of kaplibs to end up as a dependency on
their librariy. I assume that telling people to use -laif is not a
solution since it breaks the _link script paradigm. That's why I suggested
a lightweight set of link scripts for specific access to kaplibs
sublibraries.
> > I've tried to fix dipso so that it uses kaplibs_link (since it doesn't use
> > ADAM this will help a lot) but the problem is that GKS_GSTAT is used by
> > dipso to check the error status of GKS. Unfortunately this routine is
> > provided by graphpar which is specifically ADAM-based. This is unfortunate
> > since GKS_GSTAT has no ADAM in it and simply checks whether STATUS is
> > set to GKS__ERROR. Does anyone have any ideas on this?
>
> One could, presumably, change graphpar so it has separate adam and
> standalone libraries and separate graphpar_link and graphpar_link_adam
> scripts...
>
My problem with this was that the "par" in graphpar implies "ADAM
parameter system" so there is no sane way to have a non ADAM link script
:-) I can do it though.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|