On 2010.9.15 6:49 AM, Bill Moseley wrote: > I have a Catalyst application that uses Module::Install::Catalyst to copy in > all the additional files into blib when Makefile.PL is run. The painful part > is the copy -- the application is getting quite large and on some build > environments this one step is taking four or five minutes to run. It's slow > for developers that run the Makefile manually, but there's also delays in our > automated build and test environment. So, making it faster would be nice.
It should be intelligent about what it copies, copying only what changed. If you kept the build directory around between test runs that would help. > I made one quick hack to copy by creating symlinks instead of copying (on > platforms that support symlinks), but ran out of time. I'm now thinking about > attempting this again. > > So, two questions: can anyone foresee any problems symlinking into blib? And > second, if symlinks are not a good approach any other ideas how to speed up > this process? As to the former, it breaks one of the points of blib which is to have a build directory separate from the source itself. Your build might not just copy the files but modify them. Or you edit your source files and suddenly your build is acting funny. Its not something I would want to incorporate. It will probably also break packaging systems which copy blib (ironically, a performance hack) rather than installing using destdir. Hard linking would solve the latter problem, but not the former. As usual, the first thing to do is profile it and figure out what's chewing up the time. [1] It should probably be in ExtUtils::Install::pm_to_blib(), but Module::Install voids all warranties. Its possible pm_to_blib can be made a little smarter. [1] http://dl.dropbox.com/u/8332480/Profile%20or%20GTFO.png -- 184. When operating a military vehicle I may *not* attempt something "I saw in a cartoon". -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
