2008/7/28 jerry gay <[EMAIL PROTECTED]>: > On Sun, Jul 27, 2008 at 1:56 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: >> On Sun, Jul 27, 2008 at 10:08:06AM -0700, Geoffrey Broadwell wrote: >>> In the source repository, the 'parrot' in runtime/parrot/foo is >>> pointless. It's a singleton directory, and it's redundant. >> >> I think that the point of runtime/parrot/ is that we may also >> someday have runtime/perl6/, runtime/pynie/, runtime/cardinal/, >> etc. directories, which will be the canonical location for >> language-specific runtime libraries. >> > yes, that was the point at the time it was introduced. however, it > confuses the source tree with the install tree, and goes against a > parrot policy. > > in the source tree (a.k.a. your working copy), we've set up the > infrastructure for runtime/ to contain multiple language-level subdirs > for runtime components (library, include, pmc, etc.) the intent is > precisely as you suggest above. > > however, the project team has set a clear policy which states that in > the source tree, "languages must be self-contained." this policy is in > place so it will be easy to transition any language from the parrot > repository to an external repository. we still have some work to do to > make this policy both true and easy for hll developers to implement, > which will happen before parrot 1.0. following the policy, the intent > is that each language in the source tree have its own runtime > directory under the language root directory (e.g. > languages/perl6/runtime/). > > if it is determined that installations of the parrot vm and parrot > hlls will use a common prefix for a runtime root directory (e.g. > /usr/lib/parrot/runtime/), then runtime components for both the vm and > hlls may be installed to that shared location. that's an install tree > policy, and as far as i'm concerned, it hasn't been addressed yet > (along with many other install-related policies.)
If that is the idea I will be happy to work on such a patch. But I thought that the generated runtimes go to /usr/lib/parrot/dynpmc and /usr/lib/parrot/library merged with the libs from the src_dir. But then the config logic is wrong. Is there any document which describes how the config logic for self-contained installables should work so that I can fix it? It does not work now and I want to package perl6 before 1.0 without run-time access to several /usr/runtime dirs, so that people can play with it even in its current state. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
