Tim,
I've 'cvs removed' a load of obsolete stuff out of applications/kappa.
I've also moved the miscellaneous help files (for scripts, aliases,
etc) into a subdirectory, and modified Makefile.am to include these help
files in the kappa.hlp (as it stood, there were no entries for things like
lutcont, picdata, etc). Two points about the help system I notice:
1) The entries in kappa.hlp are no longer in alphabetical order, nor can
they be given the fact that the monoliths are handled separately. This is
not so good if you are using the help command to find the name of a
command.
2) There is no kaphelp command any more. You have presumably removed
kaphelp to use the new centralised help command (what is it called? - I
can't remember), but you do not seem to have set up an alias which causes
'kaphelp' to invoke this new help command.
Regarding you comment about ifd2iraf, it doesn't get run - ever. We made
a decision to drop support for iraf inter-operability (closely followed by
three resounding cheers!).
David
On Thu, 2 Sep 2004, Tim Jenness wrote:
> On Fri, 3 Sep 2004, David Berry wrote:
>
> > Tim,
> >
> > > I've finally done the promised kappa reorganization in CVS such that the
> > > ndfpack, kapview and kappa_mon task files are now in subdirectories. Much
> > > tidier.
> > >
> > > Couple of comments:
> > >
> > > - there still seems to be a lot of kaprh junk in the kappa main
> > > directory. Can that be tidied up?
> >
> > Yes, I could do that. But I'm a bit confused about the purpose of the CVS
> > repository. I thought the reason we went to the effort of importing
> > existing RCS repositories was to retain history? And the presence of (what
> > is now called) kaprh stuff in there reflects the history that it used to
> > be part of kappa. It looks like, having put the history in via RCS, we are
> > now taking it out again.
>
> Uh, no. kaprh history should be in kaprh not kappa. If it is meant to be
> in kappa for historical reasons and is now obsolete it should be 'cvs
> removed' (which retains history since the files can be resurrected).
>
> If the files should be in kappa and are not in kaprh I'm not advocating
> removing them completely from the repository itself, just cvs-removing.
> I assume that when a file goes into kaprh it's rcs file is copied (not
> moved) to kaprh and it is then cvs removed from kappa. [ie it is in two
> places in the repository but in only one place in the live tree.].
>
> Given my new reorg that would indicate that some of the kaprh files should
> be bodily moved to libkappa, libkapview in the repostiryo and then cvs
> removed such that they can be resurrected in the correct directory.
>
> >
> >
> >
> > > - it seems that files generated by ifd2star are in CVS. This leads
> > > to lots of spurious modifications relative to the CVS repository on
> > > build. Can these be removed (eg kappa_mon.tcl) When does ifd2iraf
> > > actually run? It's not in Makefile.am, only in make_unix_release.
> >
> > Again the presence of the ifl files etc are part of the history imported
> > from the RCS repository. SHould they not just go in the .cvsignore file?
>
> You shouldn't ignore a file that is actively present in the repository. If
> the cl files are important they should be there. If the cl files are
> simply generated from iraf2star so are not permanent they should not be in
> cvs. At the very least cvs-removing them will indicate that they used to
> be part of the repository but ar enow auto-generated.
>
> --
> Tim Jenness
> JAC software
> http://www.jach.hawaii.edu/~timj
>
|