Andy Dougherty <[EMAIL PROTECTED]> wrote: > > 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. > > Note that such hacking is tricky to do portably, so tread carefully.
Hmm, hadn't thought of that. There again, looking in the top-level Makefile.in, I see lines like: $(TEST_PROG): test_main$(O) $(GEN_HEADERS) $(O_FILES) Parrot/OpLib/core.pm ... ie we merrily use UNIX-style pathnames at the moment. Does this mean I can do the same for the time being? (until such time as we replace Makefiles with something Gloriously Perl-based ??? :-) > > > # all per-platform files (README, hints, header.[ch], > > # are collected together in the single directory OS// > > I'm not sure about this one. While it might make sense for some cases, > (e.g. VMS, Win32, MacOS), it might not for others. For example, some > operating systems (e.g. OpenBSD and FreeBSD) may need separate build > hints, but may otherwise be able to share most of the "generic" unix > platform-specific code. I tend to think that organizing by features > rather than by marketing names attached to particular operating systems > might be a better way to go. But that's just my opinion. In that case, my more modest proposal would be to just move all the README.$OS files to README.OS/$OS
