# from John Peacock # on Thursday 19 April 2007 03:52 am: >I was actually thinking it should be earlier in the process, > specifically in copy_if_modified().
not process_pm_files()? I guess that's going to land in copy_if_modified, just seems that putting .pm-specific code in copy_if_modified could be troublesome. >I deliberately made the "before" code invalid Perl, so that > it wouldn't be possible to run it directly out of lib. That scheme won't work in my case. See my thoughts about providing tools rather than trying to do everything via config right now. I'm not sure the '$VERSION = ' search/replace code is going to care whether you use the "##VERSION##" or some valid code, so I think that can be left up to individual project policy. I suppose we'll have at least two camps: 1. in-situ: change the code in lib/ and checkin after version bumps. This would be a build action like ACTION_setversions(). 2. on-the-way-to-blib: the code in lib/ is not complete and must have version numbers added during ACTION_code(). >The only tricky part to this would be > that copy_if_modified() would have to be smarter (since the file > *would* be modified during copying); perhaps reset the timestamp > after updating the $VERSION line??? That's not a problem. The $blib_file gets a timestamp of $now, so modifying the $lib_file at $now+1 will trigger a new copy. The tricky part would be if you wanted to SUPER::copy_if_modified() and *then* change the file -- only because it is now readonly. Aside: I have some new copying code in the wishlist of my dotReader builder, but haven't decided how to address the readonly bit yet. http://svn.dotreader.com/svn/dotreader/trunk/inc/MBwishlist/trees.pm --Eric -- Speak softly and carry a big carrot. --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
