Will Coleda wrote:
Then we can have "inst_foo" which is always the installed version, and 'foo', which depends on the current location.
Is the intention to manipulate the two versions of the config file in such a way that someone can access the various 'foo' config variables to (for example) compile a language from either a build directory or an installed Parrot with no changes to the Makefile template for the language? It should be possible, I just want to check up front that we're all working on the same goal.
If this is the goal, we're going to have to add a lot more dual variables, since many paths like lib_dir currently have no build directory counterparts. On the whole, I'd prefer *both* variants to have a prefix ('inst_foo' and 'build_foo'), then we simply alias 'foo' to the appropriate variant.
It'd also be a good idea to change the structure of the Parrot repository and tarball to more closely match the install structure, to make this kind of direct mapping possible. Such as, putting executables in a bin/ directory, Parrot library files in lib/parrot/library, Parrot includes in lib/parrot/include, Parrot extensions in lib/parrot/dynext. C includes can stay in include/parrot, but all header files that might be installed will have to go there instead of littered around the src/ directories. Put all the Perl libraries that aren't installed into a build/ directory. If we standardize on FHS internally, it will mean we need far fewer special inst_*/build_* variants, because the paths can be constructed from inst_prefix/build_prefix and inst_versiondir/build_versiondir, with the rest of the path being the same for install and build.
If the perl hash needs to be updated similarly, so be it. (Or, it can just invoke parrot_config to get the desired values if necessary)
Changing all installed tools to use parrot_config instead of the Perl module would be a definite plus.
Allison _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
