AFAIK all platforms have relatively simple ways of deploying "binary" distributions. As soon as you start talking gcc/cl/mingw/make/nmake/dmake and stop talking msi/rpm/yum/apt get/ you start talking about all sorts of forseeable and unforseeable issues and incompatibilities.

It seems to me the simplest way to do what you want is to set up clean test environments for your target platforms, get all the modules you want, do the compiles once locally, package with the appropriate platform specific tool, and deploy as ready to rock binary distros. This gives you "one command/click" install with minimal hassle. Sure it will not work every single time but it has been proven to work most of the time. Work the bugs out when and if they occur, prioritised on a most needed basis.

We're currently using TeamCity as our automated build tool, but there are many other build tools out there.

-Scott

Unfortunately we're hardware testing so we need direct access to the hardware as the parent/hypervisor sees it. We do some virtual machine testing as well so that is a good suggestion for when we tackle that area of automation.

I don't know how feasible this is, but one idea I've toyed with is doing all the installation and configuration except for the last steps (whatever steps you are testing) on a VM machine, then making an installable image of that machine and installing it onto the real hardware for the final work. It should be bit-for-bit identical to an install done directly onto the hardware, as far as I can work out.

Then do your final installation and testing.

If anything goes wrong with the configuration, you presumably will have been smart enough to have done snapshots along the way of your VMs (at various steps during the preparation) and you can just roll back to any snapshot if you need to, then fix things and push it back onto the metal.

Only problem with this is that I haven't actually done it, so I don't know for a fact that it works. It just seems like it should work.

Even if the pre-rolled Strawberry DOESN'T work, you should be able to use Perl::Dist to roll your own custom pre-build .exe

I'm not fond of windows but I'm not a zealot. I've spent about a week now trying my best to get an automation install working in windows but every time I take a step, I slam into a brick wall.

The current problem I'm facing appears to be a bug in ExtUtils/MM_Win32.pm. From another thread (http://www.perlmonks.org/?node_id=603230) I found that that module determines what the directory file separation character(s) should be. Testing it with dmake and mingw make in the path and also set in Config.pm never changes $self->make in MM_Win32.pm. Since it thinks the make tool is nmake instead of dmake og mingw make, it resorts to '^\' for a separator that doesn't work with those two make tools. I'm uncompressing the Microsoft Shared Source Common Language Infrastructure 1.0 that should have the tools in it I need according to another thread I've seen. I'm curious if it has nmake with 64bit support as well as ia64 support. If not, I'm back to square one with Windows.

As for modules that work in windows and not in linux or vice versa, that's already understood. We have a procedure in place for that. Basically we test out each module before deploying it and mark what OSes the module works in.

So the question remains, how can we build across multiple platforms in windows? Everything I see for the MS C++ compiler is 32bit only which will work for the x86_64 platforms but not for ia64 (well... it isn't ideal). Do you have experience using the Visual Studio 9.0 (free version) on the different platforms. IE does it work?

VC9 paid for, not free and then only for 32bit land. Lack of adventurous customers I'm afraid. Your problem with MM_Win32.pm illustrates one of my pet peeves in perl-land. Something I refer to as 'nix bigotry. The in-ability of unix programmers to cut code for windows and get it right. Since they all know that they are the one true way, there seems to be little effort put in coding for the evil empire. I've seen this far more often in CPAN than I like. Not that my contributions amount to all that much, but I bend over backwards in getting things right for other operating systems only to see problems like yours all around. And thats for the few that even bother to make things work for the 'other' OS! Sorry about the rant, but I've been where you seem to be more than once and for no better reason than people can't be bothered to do things correctly. Have you tried the cygwin solution yet? I've gone that way once or twice but have never stuck with it long enough to take...

--hsm

"Never try to teach a pig to sing...it wastes your time and it annoys the pig."

I've had reasonably good luck using MinGW and microsoft's nmake with PPM::Make. Occasionally, I have found a need for ExtUtils::FakeConfig to get something built, but that has been less of an issue with more recent versions of ActivePerl.

Have you looked at Cygwin? You install it on Windows and can optionally install perl and gcc. This gives you a working CPAN environment on Windows.

Did I miss anything important?

We considered cygwin but it faces the same problems we have with perl.

• A. Architecture support - we haven't looked into it enough to know if the features we need work fine on ia64 platforms. IE, does Win32::OLE work in cygwin on ia64?
• B. How do you deploy cygwin in an automated fashion with no user intervention. We already almost have this working for perl (again windows is the long pole)
• C. We still need to automagically download and install perl modules. Granted this will be much easier since we're in a unix like environment.

I suggest you also take a look at PAR.

I've used PAR::Dist::FromCPAN (actually cpan2par) to create a PAR file from a CPAN module (along with dependencies!) which can then be installed on a completely bare bones system containing just a basic Perl installation with the use of PAR::Dist.

WRT your question regarding perl on Windoze/DOS - I'd recommend strawberry perl - it comes packaged with dmake && gcc etc.

There are 2, not so much problems, as observations I would make ...

• It doesn't have an easily modifiable installation directory as it installs to C:strawberry
• The only hiccup in it's use was in the development of an XS interface to a proprietary DDL :-))

> It doesn't have an easily modifiable installation directory as it installs to C:strawberry

... but it does if you generate your own dist based on it.

Thanks for all the feedback and the interesting banter :)

For now, we have decided to just patch the MM_Win32.pm module so it works for us and then use a cpan script to install the modules we need. MinGW will be our compiler and make tool.

The PAR and Perl::Dist are things were looking into since they might make deployment easier once we have more OSes that need support but they both seem to take a lot of work from what I've read.

Once everything is put together, if anyone asks, I'll post our installer script for people to tear apart.