# from David Golden # on Wednesday 20 August 2008 14:26: >Uh, yeah, sure.... <cringe> > >http://echo.dagolden.com/scratch/
There's a 500 error on the .pl file there. >And it's very specific to the way in which I setup my distributions >and the way in which I've started embedding version numbers into Pod Adam, Ricardo, and I were discussing just this sort of thing last week on IRC. The basic pattern is that you want to automate the way you do things and you look around for an implementation, but they all have nits, so you write one of your own just for you, right? Raise your hand if you *haven't* done it! I started to try to break that issue down into pieces, which is where the 'bin/publish_module' in this repository comes from, and the config file concept where you can have a machine local config overlayed by a project config. http://scratchcomputing.com/svn/CPDK/trunk/bin/publish_module http://scratchcomputing.com/svn/CPDK/trunk/demos/trial01/.perl_developer.yml The config is intended to be able to drive the code composition, but I've found with M::B that your Build subclass can have any special actions in it such that many things reduce to a simple step of just: "./Build $action". But, I do think it is desirable to share the config across the whole process (from start of module through publication.) Anyway, what it currently does is to automate the pre-publication checks, tagging, and shipping via a linear sequence of dependent steps which are either builtin to CPDK::Publish or ./Build actions (the ones that start with '.'). Of course, by trying to make it abstract and reusable, I'm just making unnecessary work for myself because every author with more than 3 modules writes their own kit? At least, that's the impression I get whenever I mention it. --Eric -- "Left to themselves, things tend to go from bad to worse." --Murphy's Corollary --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
