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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
