On Sun Apr 06 07:39:09 2008, [EMAIL PROTECTED] wrote: > Following discussion on #parrot with Infinoid, I created the 'ops2c' > branch in our SVN repository to handle refactoring of this area of the > build system. You can follow developments there with: > > svn co https://svn.perl.org/parrot/branches/ops2c > > In that branch, I have applied Infinoid's patch to > lib/Parrot/Ops2c/Utils.pm. On Debian Linux, I have configured, built > and tested through 'make test' and everything is passing. > > So, so far, everything is cool. More to come.
Ok. The branch is now at r26827, and I feel like I've run out of hammers to hit this code with. Here's what I've done: * Move all the filehandling/opening/closing/renaming nonsense into a new function, print_c_source_file(). This complements print_c_header_file, and removes all the weird filehandle juggling stuff. * Update t/tools/ops2cutils/ accordingly. * Reorganize the file so public methods are on top. * Fix a few things in the POD. I think a TODO list would help at this point. Here are some possibilities I can think of (but don't necessarily feel very strongly about): * Honestly, I'm not really sure print_c_source_top and print_c_source_bottom need to be public methods any more. In fact, they could be merged into print_c_source_file entirely. But separating the filehandling from the printing is useful for testing... maybe they should be merged into a print_c_source_contents, or some such. * We ought to reduce the amount of boilerplate in t/tools/ops2cutils/. I changed the API of 2 functions, and had to update 5 or 6 places in the test suite. * Speaking of the test suite, is execution between "Configure.pl" and "make" really necessary? Some of the errors I was getting seemed to indicate it was generating temporary directories, so the documentation in these tests might be misleading. * So far I've been ignoring the private methods as much as possible. But they could probably use a once-over. * Even though new() delegates a lot of the work to _iterate_over_ops, it is still ginormous. Maybe it should delegate more? Its length is not necessarily a bad thing, but it makes it harder for me to understand what's going on. * Should probably get someone to test it on win32/msvc. Is there anything else that's been bugging people about this code? Mark
