Tim,
> > > + 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.
Is that a problem, given that they are always all built together as part
of a single package?
> > > + 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.
Sorry - yes, I fouled up there. I was trying to get it done too quickly!
> I also forgot to mention that KPG_AST is no longer installed. I wrote a
> kpg1_astcmn.f for common block access.
OK. Breaks a few kaplibs coding conventions (one routine per file,
routine names no more than 5 chars,...) but I suppose such concerns are
not really supportable now.
> > > 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.
But it's only present company who are likely to want to use aif isn't it?
And they are not concerned about having a dependancy on the rest of
kaplibs since they'll have it there anyway. The division of kaplibs up
into sub-libraries is pretty much arbitrary - we could simply move aif
into kpg if it looks neater. If we are really worried about this sort of
fine grain, then to be consistent should we not really be looking into
splitting kpg up into loads and loads of little packages containing
related routines, rather than having them all in one big lump?
> > > 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.
Anything can be done! It's just a case of balancing effort against
benefit, in the face of other priorities.
David
|