[EMAIL PROTECTED]: # 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 disagree. If nothing else, Configure and the Makefile (one of my areas of expertise) get messy if they have to constantly be reaching into subdirectories. I do, however, think that some of the more specialized stuff can be moved into 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 # # 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 I think this is the closest of your three options. Basically, Perl will just be one .so (or .dll, or whatever) that Parrot can load on demand. It will probably be built alongside Parrot. (Actually, it'll also be an executable that embeds Parrot, but whatever.) # 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 Are these nested? If so, okay, as long as Configure itself is in the root directory. If not, ugh. That'll fill Configure with complicated paths, like ../parrot/include/parrot/config.h. # 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 No. Hints are part of Configure--they should stay with it. # 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 Why? I think four .ops files mixed in with C code is okay. # # better here ? # # vtable.tbl classes/vtable.tbl That's a toughy. I think it stays in the root directory. # # 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 This should be in the root directory. # make_vtable_ops.pl scripts/make_vtable_ops.pl # manicheck.pl scripts/manicheck.pl This too. Both of these have general utility. Manicheck isn't used during a normal build. # 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 Why not put these with Configure? Or in a directory called build? # # 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. Why don't we put the PDDs with the other docs? --Brent Dax [EMAIL PROTECTED] Parrot Configure pumpking and regex hacker Check out the Parrot FAQ: http://www.panix.com/~ziggy/parrot.html (no, it's not mine) <obra> mmmm. hawt sysadmin chx0rs <lathos> This is sad. I know of *a* hawt sysamin chx0r. <obra> I know more than a few. <lathos> obra: There are two? Are you sure it's not the same one?
