I've only had one reply to this so far - anyone else want to approve or disapprove?
NB - I'm kind of offering to do the patching of paths required if this move goes ahead, but obviously I can't do the moving on the CVS server myself. Dave. ------------- Begin Forwarded Message ------------- Date: Sun, 3 Feb 2002 23:24:16 GMT From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Parrot directory structure 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. ------------- End Forwarded Message -------------
