Tim,
> David, since you're back, can you have a quick look at the "possible
> refactoring" section of the wiki and comment on my kappa/kaplibs notes?
I've removed the item under kappa about the irg_err and ctg_err files -
irg hasn't been used in kappa since GRP became available (I've removed
the relevanet files from the repositiry and modified the Makefile.am),
and ctg_err is part of kaplibs not kappa.
> In essence, at the top of my list:
>
> 1. Move the kappa_mon application .f files to kappa_mon directory,
> move ndfpack_mon stuff to ndfpack and kapview_mon to kapview
> directories. I would leave the toplevel .f files in the toplevel
> but all the application files would be tidier in subdirs
OK
>
> 2. Change the link so that only ndfpack (!) links against tk.
> [no reason for kappa_mon and kapview to include tk in the link]
> This would require a libtkkpg to be made.
OK. And your comment on the wiki about whether ndfpack needs pgplot - I
believe ther answer is no (at least, none of the ndfpack ifl files contain
a DEVICE parameter).
> 3. Actually, change kaplibs so that it has a -notk option
> so that it is possible to link against kaplibs without
> dragging in libtk.
OK.
> Much of this came out of the porting to OSX exercise since it was becoming
> obvious that most applications linked against tk even though they didn't
> use it.
>
> If you approve of these changes I'll start fiddling [with the reorg of the
> application fortran files it might be better to move them in the
> repository to retain history and just act as if they were never in the
> toplevel]
OK.
Regarding the other items in the list, it's been so long since I had any
dealing with messgen that I have forgotten what the benefits are of using
messgen to generate your xxx_err file rather than creating them by hand.
Is it just that you are saved the effort of calculating the error code
values from the facility number? Regarding the benefit of reverse
engineering msg files from the existing xxx_err files, I suppose it would
not do any harm but I cannot see much benefit either!
Regarding the need for a standalone kaplibs_link command, I've not been
following the debate too closely. Are there currently any outstanding
problems (e.g. dipso)? Obviously, it would be more consistent if there
were a kaplibs_link command.
Over-all, I have no problems with any of these changes being made.
David
|