On Sat, 3 Nov 2001, Zach Lipton wrote:
> parrot. The idea is to have the Configure.pl script itself run .cm files
> located in Config/, these .cm files (configuremodule) would do the actual
> work of configuration. The Conf.pm module would contain a set of API's for
> the .cm files to call. (this is all portable of course...) An example .cm
> file would be like:
> So anyway, what do you think about this? Again, I have real code which I can
> supply, but am I way offbase here? To me, the main advantage is getting
> everything out of a "monster-script" and breaking it up into packages.
Yes, this is how metaconfig works to generate the monster Configure script
used in Configuring perl. I happen to think that's a pretty good plan:-).
(One superficial difference is that all the little .cm files (called .U
units in metaconfig) get smashed together into a big Configure script in
perl5, but that's just a cosmetic issue at the end of the assembly
process. There's no compelling reason for it.)
If I were designing units for Parrot's Configure, I'd probably set up the
different sections in a metaconfig unit sections as POD sections:
=for config.h # Stuff to go in config.h
=for Configure # Stuff to get run as part of Configure
=for make # Dependency info so metaconfig knows how to
# assemble all the different parts
=for metalint # For running metalint to check the units.
There are probably others too that I forget offhand, but you get the idea.
Also, in the part that goes into Configure, I'd include pre- and post-
hooks (a better version of the "call-back units" that are in Perl5's
Configure.) Those hooks would normally be empty, but could be overridden
by hints files.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
