Hi Dave,
I agree with your config/ dir suggestion, but I'm not sure about
moving everything else down into perl6/parrot subdirectory,
at least not yet. I like having the parrot repos as a separate
module that could be checked out into a perl6 tree, so then you
could do something like:
cvs co perl6
cd perl6 ; cvs co parrot
Just one opinion, however, and I'm not even sure if it makes sense.
I assume Simon could answer this; maybe what I said doesn't even make
sense.
1) Will Perl6 and Parrot distributions be separate?
2) Should/would perl6 (lex, parser, code-gen, etc.) build without Parrot in
the first place?
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
Dave Mitchell
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
.uk> cc:
Subject: Re: Parrot directory
structure
02/07/2002 07:16
AM
Please respond to
Dave Mitchell
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 -------------
