Classic example is Cwd. CPAN uses Cwd internally. This means the Cwd.dll is locked when you try to build and install Pathtools from CPAN shell. The simple solution is to exit CPAN and go to the Pathtools directory and do the build by hand. But that only works if you are using ExtUtils::MakeMaker to do the build. If you use Module::Build then you have the same problem as CPAN would as MB also uses Cwd.dll
Likewise this problem shows up in situations where you are upgrading XS modules that are in use elsewhere in the system. For instance i have some processes that run 24 hours a day. With the updated ExtUtils::Install I can install new versions of XS modules that this process uses, and it Just Works. Without the new version EU::I Just Fails because the dlls are locked and cannot be deleted.
The strategy employed by the newer EU-I code is to try to rename the locked dll to a temporary name, install the new code, and schedule the renamed dlls for deletion at boot. If the rename fails it installs using a temporary name and arranges the replacement of the in use file at reboot.
So, there are a variety of ways that you could avoid needing this functionality, but that doesnt mean the functionality is unneeded.
In reply to Re^6: [JOB] The Perl Foundation seeks Windows Developer
by demerphq
in thread [JOB] The Perl Foundation seeks Windows Developer
by adamk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |