On Fri, Feb 08, 2002 at 01:18:20PM +0000, Dave Mitchell wrote: > Simon Cozens wrote: > > Dave Mitchell: > > > I'm trying to nip the following in the bud, which is daunting for someone > > > trying to work out what's what for the first time. > > > > > > ls perl-current/ > > > > I see your point, but I don't think 'ls perl-current/src' is much better. :) > > True, but the point is that ls parrot/ *would* be better: > > Configure.pl MANIFEST README classes/ config/ doc/ > pdd/ pod/ src/ > > (or thereabouts) > > I'd like it if the src directory only contained zillions of *.[ch] > files, and didn't have other random stuff mixed in with it. > > It really boils down to two things: > 1) do we want to group similar things into directories (src, config, doc > etc), > 2) do we want all the directories at the same level, or should the > the src be the parent directory of the others. > > I guess we agree on (1), and disagree on (2).
Two other things I thought of which I believe have been touched on (or close) earlier: 1: It is nice to have the option of building the object files outside the source directory. This lets you keep your source directory "clean", and also lets you build more than one architecture's parrot from the same directory. [and probably some other things I've not thought of, such as building from a source directory that is actually still on CD ROM] 2: [Even if we don't do 1] it might be nice to have object files in their own subdirectories. This makes it easy for a parrot developer to archive away one set of object files, and recompile with other compiler options (such as profiling) It also means that where normal parrot might automatically be building code both for a shared libparrot.so (or the like) and for a static linking libparrot.a, for which different compiler options are needed and different code is generated then we just have 2 directories with .o files in them, rather than messy games with .o and .lo files. (IIRC this is how some GNU stuff does this sort of thing, and it feels less portable) Nicholas Clark -- EMCFT http://www.ccl4.org/~nick/CV.html
