parrot_config RFC

[Jeff Horwitz]

in #parrotsketch last week i brought up the interesting output of 
parrot_config, and allison asked for an RFC.  here it is.

most parrot_config values are literal strings, simple enough.  for example:

ldflags => ' -L/usr/local/lib'
libdir => '/usr/local/lib'
libexecdir => '/usr/local/libexec'

others, however, contain Makefile variables that would need to be expanded 
before use.  for example:

libparrot => '$(LIBPARROT_SHARED)'
libparrot_shared => 'libparrot$(SHARE_EXT).$(SOVERSION)'
libparrot_shared_alias => 'libparrot$(SHARE_EXT)'
libparrot_soname => '-Wl,-soname=libparrot$(SHARE_EXT).$(SOVERSION)'

some are simple, but others, such as libparrot, would require several 
iterations to expand.  when i want to know the name of the shared 
libparrot, the last thing i expect to see is 
'libparrot$(SHARE_EXT).$(SOVERSION)'.  it makes me work that much harder 
for a simple bit of information.

it also *forces* the use of a Makefile.  for most projects that won't be a 
problem, but what if i want these values during a configuration stage, 
pre-Makefile?  that's how GNU configure scripts work, and embedded 
variables would break it horribly.  outside of configure, i could write 
something to expand the variables, but why not do that for the programmer 
in the config itself?  and what if i have my own $(SOVERSION)?  i have to 
rename it now?

so, to the point.  is there a reason we're using embedded Makefile 
variables in parrot_config values?  my guess is that it's legacy, and if 
that's the case i strongly recommend expanding these variables.  the only 
consequence i could think of is what if a value changes?  the answer here 
is to reconfigure -- if one of these values changes, you should probably 
be reconfiguring anyway.

comments please!

-jeff