On Tue, 15 Jun 2004, Malcolm J. Currie wrote:
> > Are these gen files any use? We should probably put the old RCS etc stuff in
> > cvs, but only in a way that keeps the history, we could have some directory
> > which is not part of the build.
>
> If it helps set up matters before the Tiger-team week, my pre-1998 CVS
> repositories for PAR (CONVERT, HDSTRACE, and KAPPA) are in
> rlsaxps:/home/user1/mjc/cvsroot.
>
> Would the pundits please comment on my directory structure in the new
> scheme of things, and the best approach for importing the new and old
> generic files and other ancillary files not part of earlier releases.
>
> For example, would it be easier if I merely update my PAR CVS with
> Alan's changes? I suppose one can use -admin to modify the change date
> to correspond to the history in the prologues.
How extensive are the diffs between the current CVS files and these CVS
files?
If minimal, you can copy in the ,v files directly into the new CVS
location. Move out the current files. CVS update. Copy the new files back
in, and cvs commit.
The main issue is the directory layout. It's currently a single directory
with all the source code and documentation in.
- Should we be putting documentation in subdirectories? [it's tidier that
way but complicates the build system]
>
>
> cvsroot/par:
> build doc errmsg exerciser help include_files lib test
>
> cvsroot/par/build:
> unix vms
>
> cvsroot/par/build/unix:
> mk,v unix_include.sub,v unix_makefile,v unix_par_dev,v
> unix_par_link_adam,v
>
The par_link_adam is the only relevant file from these directories.
Not sure what the .sub files is though.
> cvsroot/par/build/vms:
> build.com,v generic_expand.com,v par_link_adam.opt,v
> build_image_adam.com,v link_image_adam.com,v split_generic.com,v
> build_library.com,v par_dev.com,v unix_release.com,v
> build_library_module.com,v par_generix.lis,v vms_release.com,v
> forconv_dir.com,v par_image_adam.mar,v
Lose it.
>
> cvsroot/par/doc:
> par_cancl.tex,v par_gdr1x.tex,v par_grm1x.tex,v par_promt.tex,v
> par_choic.tex,v par_gdrvx.tex,v par_grmvx.tex,v par_put0x.tex,v
> par_choiv.tex,v par_get0x.tex,v par_gtd0l.tex,v par_put1x.tex,v
> par_def0x.tex,v par_get1x.tex,v par_maxx.tex,v par_putnx.tex,v
> par_def1x.tex,v par_getnx.tex,v par_minx.tex,v par_putvx.tex,v
> par_defnx.tex,v par_getvx.tex,v par_mix0x.tex,v par_state.tex,v
> par_exacx.tex,v par_geven.tex,v par_mixvx.tex,v par_unset.tex,v
> par_gdr0x.tex,v par_godd.tex,v par.news,v sun114.tex,v
This is interesting. Aren't the .tex files generated automatically from
the source code using SST? If they are then presumably we can just
use a template sun114.tex and generate the final sun114.tex with the build
system. This assumes no manual tweaking (AST does this).
>
> cvsroot/par/errmsg:
> par_err.msg,v
>
How much history is in here? You could copy that in over the top of the
existing CVS entry (I assume it's identical to the current version).
> cvsroot/par/exerciser:
> exercise_makefile,v parexercise.f,v parexercise.ifl,v
>
I assume this is a test routine. Can it be run automatically or is it
interactive? Does it differ from par_test.f that is already there?
[but currently not enabled]. I'm happy for exerciser to go in a
sub-directory like ast_tester.
> cvsroot/par/help:
> par_cancl.hlp,v par_gdr1x.hlp,v par_grm1x.hlp,v par_put0x.hlp,v
> par_choic.hlp,v par_gdrvx.hlp,v par_grmvx.hlp,v par_put1x.hlp,v
> par_choiv.hlp,v par_get0x.hlp,v par_gtd0l.hlp,v par_putnx.hlp,v
> par_def0x.hlp,v par_get1x.hlp,v par_maxx.hlp,v par_putvx.hlp,v
> par_def1x.hlp,v par_getnx.hlp,v par_minx.hlp,v par_state.hlp,v
> par_defnx.hlp,v par_getvx.hlp,v par_mix0x.hlp,v par_unset.hlp,v
> par_exacx.hlp,v par_geven.hlp,v par_mixvx.hlp,v
> par_gdr0x.hlp,v par_godd.hlp,v par_promt.hlp,v
>
Similarly to tex files. SST? or manual?
> cvsroot/par/include_files:
> par_dummy.f,v par_err.f,v par_par.f,v
>
Why are there .f extensions? PAR_PAR is in CVS. PAR_ERR is derived by
messagen. The PAR_PAR history can go in (without the .f).
> cvsroot/par/lib:
> par1_abset.f,v par_exacx.gen,v par_godd.f,v par_put0x.gen,v
> par1_menu.f,v par_gdr0x.gen,v par_grm1x.gen,v par_put1x.gen,v
> par1_qrstx.gen,v par_gdr1x.gen,v par_grmvx.gen,v par_putnx.gen,v
> par_cancl.f,v par_gdrvx.gen,v par_gtd0l.f,v par_putvx.gen,v
> par_choic.f,v par_get0x.gen,v par_maxx.gen,v par_state.f,v
> par_choiv.f,v par_get1x.gen,v par_minx.gen,v par_unset.f,v
> par_def0x.gen,v par_getnx.gen,v par_mix0x.gen,v
> par_def1x.gen,v par_getvx.gen,v par_mixvx.gen,v
> par_defnx.gen,v par_geven.f,v par_promt.f,v
These can go straight into CVS so long as you also remove the derived
files that are no longer useful. Again copy everything into CVS, cvs
update, copy the current files into the directory and commit.
The Makefile.am files will need .gen support.
>
> cvsroot/par/test:
> par_test.f,v par_test.ifl,v
>
Ah ha. This is the test files.
I don't see any real need to retain this directory structure though.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|