I think your suggestions sound pretty good to me. Personally, i'd lean towards possibility 2, since 1 is doable if you plan for 2, but not necessarily vice-versa.
Otherwise I think your proposal sounds good. But then again i'm nobody ;) --Josh At 23:24 on 02/03/2002 GMT, [EMAIL PROTECTED] wrote: > Parroteers, > > I've been thinking about the directory structure of Parrot. > Currently, the top-level dir is a bit of mess, with zillions of > files of various flavours. It is my contention that apart from > a few expected files such as README, MANIFEST, Configure.pl etc, > everything else should be in subdirs. > > I have some provisional suggestions for this below. > > First however, I want to clarify the packaging of parrot vs perl6, because > this will affect the depth of directory hieriarchy needed. > > I can see 3 main possibilites: > > 1. Perl 6 and Parrot come as essentially two separate packages, with their > own config scripts etc. > > this suggests two separate tarballs > > 2. They share config, but are separate otherwise > > this suggests a single tarball with just config/, perl6/, parrot/ subdirs > > 3. They are completely intermixed, sharing some src files, pre-processing > scripts, etc etc. > > again, a single tarball, but with lots of top-level subdirs > > For the moment, I've assumed (1); some of the suggested directory > names below may need parrot/ prepending to them if (2) or (3) is the > case. > > Anyway, here's how I suggest files should be moved around to make > a more rational directory hierarchy. This will involve quite a bit > of hacking of paths in makefiles, scripts etc; but if we're going > to do it at all, then the sooner the better. > > Comments? > > ------------------------------------------------- > > original file renamed to > ------------- ---------- > > > # parrot/ holds general src code for parrot > > *.[ch] parrot/*.[ch] > > # config/ holds files associated with the configuration process > > Config_pm.in config/Config_pm.in > Makefile.in config/Makefile.in > Types_pm.in config/Types_pm.in > config_h.in config/config_h.in > test_c.in config/test_c.in > test_gnuc.c config/test_gnuc.c > testparrotfuncptr.c config/testparrotfuncptr.c > test_parrot_sizes.c config/test_parrot_sizes.c > > # all per-platform files (README, hints, header.[ch], > # are collected together in the single directory OS// > > README.OS_X OS/macos_x/README > > hints/cygwin.pl OS/cygwin/hints.pl > hints/darwin.pl OS/darwin/hints.pl > hints/mswin32.pl OS/mswin32/hints.pl > hints/os2.pl OS/os2/hints.pl > hints/vms.pl OS/vms/hints.pl > > platforms/win32.h OS/win32/platform.h > platforms/win32.c OS/win32/platform.c > platforms/generic.h OS/generic/platform.h > platforms/generic.c OS/generic/platform.c > > # bin/ holds executables for 'end-user' use > > assemble.pl bin/assemble.pl > disassemble.pl bin/disassemble.pl > optimizer.pl bin/optimizer.pl > > # ops/ holds *.ops files > > core.ops ops/core.ops > io.ops ops/io.ops > obscure.ops ops/obscure.ops > rx.ops ops/rx.ops > > # better here ? > > vtable.tbl classes/vtable.tbl > > # scripts/ holds scripts used during the build process, eg > # to pre-process .c files etc > > jit2h.pl scripts/jit2h.pl > make.pl scripts/make.pl > make_vtable_ops.pl scripts/make_vtable_ops.pl > manicheck.pl scripts/manicheck.pl > ops2c.pl scripts/ops2c.pl > ops2pm.pl scripts/ops2pm.pl > pmc_pm.pl scripts/pmc_pm.pl > vtable_h.pl scripts/vtable_h.pl > > # for consistency these two should be moved too: > > classes/genclass.pl scripts/genclass.pl > classes/pmc2c.pl scripts/pmc2c.pl > > # tmp/ > > this should be an intially empty directory; build scripts that ned > to create transient files should try to put them here where possible > > # pdd/ > > all the PDDs really should come under control of CVS.
