Looking at examples of how to compile and link against parrot (examples/embed and plparrot), it appears to me that parrot_config is answering questions at the wrong level. In stead of questions like "What flags do I need to use to compile a C file which #includes parrot headers?", "What linker flags do I need to use to link against libparrot?", or "In which directory does parrot keep languages?"; it answers questions like "What is parrot's base include directory?", "Where do you think the ctags tool is?", "Where were the core parrot tests on the machine that built you relative to the build dir?", and "Where does parrot install info files?". The first must be combined with knowledge of how parrot installs itself to be of any real use, the second is silly (parrot isn't exactly the first authority I'd consult about ctags), the third is completely irrelevant for any installed parrot, and the fourth is a red herring (parrot doesn't install info files, or even create this directory).
As I see it there are 3 separate consumers of configuration values, each with different priorities: * parrot build-time * parrot run-time * parrot_config (also, config.pir) Parrot build-time is the user to which the system primarily caters at the moment. Parrot run-time massages out the information it actually needs from 4 of the over 200 hash entries. See parrot_init_library_paths() for details. parrot_config makes available all the available information available, unaltered, undescribed. But as aluded to earlier, this is far too low level for parrot users. We're currently treating all consumers as if they were the same and neglecting the interests of all but the first. I propose we support each config consumer separately. Build-time is happy how things are - no changese necessary. Run-time and parrot_config should get separate configuration hashes, both based on the raw config data, but tuned individually to their particular objective. The run-time config hash would be fairly small, likely 4 to 8 entries, the bare minimum to actually have parrot operational. parrot_config would have a hash about the size it hash now, but with answers targeted towards parrot users. Each parrot_config entry would also come with a brief description of exactly what it means (quick, what's the difference between inst_libparrot_ldflags and inst_libparrot_linkflags?). _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
