RFC: separate configuration value lookup mechanisms

Peter Lobsinger plobsing at gmail.com
Wed Nov 17 03:20:53 UTC 2010

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
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?).

More information about the parrot-dev mailing list