parrot_config RFC

[bsdz]

On 17 May, 14:36, Jeff Horwitz <j... at smashing.org> wrote:
> 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!


Not an answer to your question but thought since you are writing an
RFC I should bring this up.

Right now parrot_config outputs data in a Perl readable format. This
is perhaps a little bias considering Parrot is trying to encourage
other HLLs to be developed. I can see arguments for keeping such
formats as POD for documentation but parrot_config should really be
outputting something like JSON or XML.

If using JSON there have been suggestions to allow references that
have been incorporated into the Dojo toolkit. For more info see: -

http://www.json.com/2007/10/19/json-referencing-proposal-and-library/