Re^4: Semicolon delimited to Comma delimited

[swatzz]

Haha! Well since you ask, i have nothing against CPAN modules. I have used many in the past for developing my work products. The problem arises mainly because of Perl versions. Some modules run on some versions and not all end users have the version i use for developing the tool. Now this is where a conflict is already building up. Then comes the problem of people mostly preferring to use what comes bundled in Active Perl. Asking them to additionally use a CPAN package is mostly ignored!! Even if people are ready to go the extra way and download the CPAN package that needs to be there in addition to default Perl packages, they particularly dont pay attention to the versions!

So in all its a bummer, especially if my tool is to be used by some user sitting in another continent! I end up more time sorting out the Perl/Perl libraries issues. So there you go, that's my cause for reticense!!

[dasgar]

Here's another route that you can consider.

On your development system, use a 32-bit Perl installation - unless you need 64-bit features (like 64-bit integers) and know that everyone is using 64-bit Windows. I'd recommend using Strawberry Perl since it includes the compiler tools needed to install CPAN modules. If you prefer to stay with ActivePerl, then I'd recommend using PPM to install dmake and MinGW from ActiveState's repository, which makes it easier to install modules that need to be compiled.

Then install PAR::Packer, which will give you the pp utility. Now you can use any module that you want from CPAN and use pp to bundle your script into an executable that you can distribute to others. Going this route, it doesn't matter if the other person has Perl installed or not since the executable contains a copy of the Perl interpreter and needed modules from your development system. For some modules that require libraries to be installed, you can tell pp to include those libraries too.

Here's a few downsides that I can think of for going this route. First, obviously the executable can't be run from multiple OSes. But since you're using Win32::OLE, your existing script will only run on Windows anyways. Second, the executable will be much larger than your source code. From my perspective, having larger files to distribute is a small price to pay to gain the benefits of using anything from CPAN and not having to deal with figuring out why someone's Perl installation isn't running the script properly. And lastly, others can't tweak your code if they wanted to. But that can be a good thing too in that you don't have to deal with "I changed XYZ in the code its broken now and I need your help to fix it" type requests.

That's route that I have taken with some of my Perl scripts at work. Much easier than trying figure out if someone has Perl installed and figuring out what distribution/version of Perl is installed and what modules are installed and what versions of those modules installed. I've even had a situation where I shared a Perl script with a co-worker and it behaved totally different on his system due to differences in Perl environments. So I packed my script into an executable and gave that to him and it worked fine on his system.

Also, I need to point out that by using a 32-bit Perl, you'll be creating a 32-bit executable, which can be run on both 32-bit and 64-bit Windows. However, if you use a 64-bit Perl, I think that you're only going to be able to create a 64-bit executable, which obviously can't be run on a 32-bit Windows system.

Anyways, thought I'd point out another alternative for you.

[marinersk]

Makes total sense. The greatest common denominator multiple in an undisciplined environment is often very low. If you can't control the environment, you control the risks you insert into that environment.