LMPX.COM |
Home | Linux | Mysql | PHP | XML | ||
|
|
|||
From: Eric Wilhelm Date: Mon Aug 4 11:46:49 2008 Subject: Re: more META.*.yml files
# from Shlomi Fish # on Monday 04 August 2008 04:14: >> But a patch demonstrating what you want would probably be more >> convincing, in that we could much better understand what it is you >> want. > >I think I can accomplish that using a sub-class, so that will be my > first lead. I'll also do it TDD-style, so you can understand what I > mean using the tests. Just write some code that does what you want to do. I recommend that it is neither a patch nor a subclass. #META.in.yml add_to_cleanup: - Math-Vec-* - META.yml create_makefile_pl: passthrough dist_version_from: lib/Math/Vec.pm license: perl module_name: Math::Vec test_requires: Test::More: 0 # Build.PL ... use YAML; my $builder = $build_class->new( %{YAML::LoadFile('META.in.yml')}, ); Done? Of course there's the hang-up that not all build parameters turn into META.yml, so it would be nice to have some parallels between them instead of needing to put a meta_merge in your META.in.yml. There is the problem of now needing configure_requires => YAML, but you might as well since patching Module::Build::YAML to support Load() would just mean adding a configure_requires for a newer M::B. The point is to minimize the barrier to installation without being totally bored as an author, so maybe just have a Build.PL.in template and a tool to instantiate the Build.PL. $template =~ s/^\s*# PARAMETERS GO HERE.*$/$params_string/m; Obviously, not all dependencies can be static - thus the Build.PL and the dynamic_config flag. But your tool could certainly just conjure a stock Build.PL boilerplate if it doesn't find a Build.PL.in file. We've also talked about a META.local.yml file as a way for the installer toolchain to have a more uniform handling of dynamic_config => 1. In theory, I could set dynamic_config => 0 in my META.yml and quit shipping a Build.PL file, right? Ah well, one can dream. By the way, saying "because I want to" is a terrible answer to "why?". Perhaps you hove some reason like being able to automate module publishing, simplifying input data, or eliminating troubles with stale templates. I've probably had 2-3 episodes of hacking together some shell and perl translations to my Build.PL files (of which there are 60+ in my checkouts dir atm.) --Eric -- Minimum wage help gives you minimum service. --David Schomer --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
| Navigate in group perl.module.build at sever nntp.perl.org | |
| Previous | Next |
| © No Copyright You are free to use Anything |
Site Maintained by PHP Developer
Powered By PHP Consultants |