Hi all,
I'm thinking of adding some new copy+fixup functionality to M::B. For
context, I'm working on a (hackish) process_inline_files() for an
Inline::C subtree.
Could you please ring-in with "yes that hurts for me too" or "no, you're
doing it all wrong"?
I'm looking/wishing for a way to munge a file's contents on the way to
e.g. blib/lib/. For instance, process_foo_files() would be terribly
convenient if copy_if_modified() could hit a callback rather than
File::Copy::copy() *after* creating the basedir and before the chmod.
[Note, the chmod makes it inconvenient to do:
$self->copy_if_modified(from => 'lib/Foo.foo',
to => 'blib/lib/Foo.pm') and $self->foo_munge("blib/lib/Foo.pm");
but that's actually a bit wordy, so I still think it hurts elsewhere.]
Though I don't think that really scratches the itch. I'm trying to
aggregate some scattered pain-points involving populating blib, so
please bear with me and/or read along:
http://svn.dotreader.com/svn/dotreader/trunk/inc/MBwishlist/trees.pm
That's what I used to scratch this itch the last time it was really
bugging me. Now I've got something in another project and want to get
around having to employ copy&paste code reuse.
I think the generic case is roughly:
* source tree/list of files
(e.g. foolib/ or ala `find lib -name '*.x'`)
* destination root
(e.g. "blib/foo/" or "blib/lib/")
* possibly needing changes along-the-way
* should be read-only when done
So maybe this could be satisfied with something like:
my @copied = $self->copy_files([EMAIL PROTECTED], $todir); # see trees.pm
$self->munge_in_place([EMAIL PROTECTED]); # supplied by user
$self->chmod_files([EMAIL PROTECTED]); # wishlist item
Following the lead of copy_if_modified(), I made copy_files() return the
destinations.
Note1: Though possibly that should return a hashref of
{$fromfile => $tofile} pairs where exists($hash->{$fromfile}) is only
true if it was copied.
Note2: And I suppose chmod_files() would want said hashref for the
is-executable check on $fromfile.
Hmm, so:
my $copy_info = $self->copy_files([EMAIL PROTECTED], $todir);
$self->munge_in_place([values(%$copy_info)]);
$self->chmod_files($copy_info);
But that leaves munge_in_place() with the task of open, read, munge,
open, write vs the much handier sub {s/^#PUT THING HERE/$thing/} usage
that would be enabled if copy_files() took a "fixup => sub {...}"
option, right? Thus, the more common usage might be just:
$self->copy_files([EMAIL PROTECTED], $to_dir,
fixup => sub {s/^#PUT THING HERE/$thing/}
);
Where fixup is called as:
while(local $_ = <$infh>) {$fixup->(); print $outfh $_}
So now the questions:
Useful?
What did I miss?
(besides the todo bit "if($^O eq 'os2')" from copy_if_modified())
Is "fixup => sub {...}" better written as map_lines => sub {...}?
Should we do "$opts{nochmod} or $self->chmod_files($copy_info)" before
returning from copy_files()?
That is, would the three-step shown with the munge_in_place method
also be required?
And/or would an after_copy => sub {open(my $fh, '<', $f); ...;
open($fh, '>', $f); print $fh "$thbbt";} option be better than the
three-step (avoiding "oops forgot to chmod".)
What about mixed (e.g. ".pm" and ".cpp" trees)? Should there be a
"where" selector of sorts on the fixup option? Maybe done as
"fixup => {lines => sub {...}, where => sub {...}}" -- this implies a
"fixup => {file => sub {...}, where => sub {...}}" which would sort of
answer the whole question about after_copy and the three-step thing
too.
Wow you read this whole thing? Cool.
Thanks,
Eric
--
But as soon as you hear the Doppler shift dropping in pitch, you know
that they're probably going to miss your house, because if they were on
a collision course with your house, the pitch would stay the same until
impact. As I said, that's one's subtle.
--Larry Wall
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
