# from David Golden
# on Saturday 18 April 2009 04:08:
>> Module::Build::Functions, anybody? *grin* [Thinking of the module
>> purpose as being analogous to the differences in use between
>> File::Spec and File::Spec::Functions]
>
>It really wouldn't be very hard to crib the easy style of M::I for
>simple M::B modules.
I've been thinking that a developer tool would simply read distin.yml
and generate a Build.PL. This probably starts to resemble distzilla.
And perhaps even just exec() some builder.pl script if you really want
the function-based mini-language (a 'FunL'). Or, simply define and
parse a real DSL.
The difference in what I'm thinking vs what M::I does is that there's no
need to bundle the developer's tool -- just print a Build.PL or maybe
use Module::Build::YAML to slurp arguments into the call to new() if
the Build.PL really needs to do something special. Again, distzilla
already does something like this.
I've also been thinking about how plugins can cleanly address the
difference between the developer's (full-featured) setup and the "just
install" target machine. This line of thought has led me to believe
that maybe the "perl Build.PL ; ./Build ..." interface is not used on
the developer's machine (the thinking being that if you generate a
Build.PL, you don't want some code about conditional plugins to cause
errors on the "just install it" targets (e.g. CPAN clients), thus you
simply keep all of that logic of plugin loading &c in an external
tool.)
--Eric
--
"Time flies like an arrow, but fruit flies like a banana."
--Groucho Marx
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
