Project Installations

barbie on 2003-09-25T13:49:20

Having had the joys last week of having my project undergoing testing, the only testing so far has been on the installer. Much of this has been down to my misunderstandings and also the fact that installing additional binaries wasn't part of what I planned. As a consequence of this I've learn a few things.

  1. When designing or programming your project, remember to consider whether the installation of additional binaries is required or a burden.
  2. PPM.pm backend installs from the off. CPAN.pm will probably hang.
  3. Win32::AdminMisc, which although a nice module, includes a call to GlobalMemoryStatusEx() which is not supported on WinNT (the target machine)
  4. WinNT ignores registry settings for PERL5LIB, and doesn't seem to respond to the AUTOEXEC.BAT setting either.

The first was easily rectified, as the XML dependancy was removed in favour of the INI config file layout.

Due to the size of the installer, I decided the additional modules should really be installed over the 'net. I got PPM to install PPM::Repositories and load up any new repositories, then listed all the modules I wanted installed. Some, such as Template-Toolkit, that aren't in ActiveState's repository can then be installed. However, there are some modules that don't exist in any PPM repositories, such as File::Find::Rule. Initally I figured that CPAN.pm could handle it, but alas no. Unfortunately, if there is a way to default the configuration interaction through the backend, I haven't found it. As CPAN.pm hasn't been run before, the module is trying to do a bit of user interaction when there isn't any user. Thus the whole installer just hangs. So for these extra few I have now created my own PPD files, and let PPM install them.

Win32::AdminMisc looked like the only module that did the job I needed, but on further investigation, Win32 does it too, which is part of the libwin32 suite.

The last one is the greatest source of annoyance. I've had to write a section of code to update the 'use lib' line of all the .pl and .cgi scripts to include the absolute path to the local lib directory. I don't like doing that as it gives too much away.

It's actually been a blessing, as now three modules have been simplified and run alot quicker.


Use the NT version

djberg96 on 2003-09-26T15:07:55

Win32::AdminMisc, which although a nice module, includes a call to GlobalMemoryStatusEx() which is not supported on WinNT (the target machine)

According to the MSDN site, you should be able to use GlobalMemoryStatus() on WindowsNT. The docs say that you only need GlobalMemoryStatusEx() if dealing with more than 4GB of main memory. Simple enough to patch with an #ifdef I would think.

Re:Use the NT version

barbie on 2003-09-27T10:25:29

Thankfully for this project I wasn't using much of Win32::AdminMisc, and there was a solution I could use inside Win32, which is bundled with ActivePerl. But thanks for the pointer. It may be useful in the future.