/me nods... ... but, on the other hand ...
Many packages in Perl are actually compiled in-place, and as such, they could be quite dependent upon their surroundings. Whether a particular external DLL or .so exists, exactly what one was linked-in, and so on. So, what I think that I’d do, instead, is to make a build on an actual representative i386 system, and then clone that to the i386 systems as needed. I’d feel a whole lot more confident about that.
| |
Many packages in Perl are actually compiled in-place, and as such, they could be quite dependent upon their surroundings.
Compiled in-place? You mean they override themselves during compilation? I've never encountered that.
If not, could you maybe elaborate on what you mean by "compiled in-placed"? Are you talking about dynamic linking?
| [reply] |
What I mean is that, if you watch a great many packages in the process of being installed, you see a C or C++ compiler running. This is how the dynamic-link libraries are constructed: they’re not downloaded in binary form, but built on-the-spot.
Therefore, I suggest that, if you’re going to deploy an application and its packages onto a particular target, you maybe ought to (if possible) actually build your master-copy on a “typical” example of exactly that target system. Now you have a plausible reason to expect that, whatever dependency there might be upon “the surroundings,” those “surroundings” will be the same. To me, that is the approach that is least likely to produce unwanted phone calls at two o’clock in the morning. :-) I am therefore suggesting that “what I would choose to do is...” to create a 64-bit master copy for my 64-bit machines, and a 32-bit master copy for my 32-bit machines. (After ensuring of course that all of them are maintained at identical operating-system service levels.)
A deployed app can easily involve dependencies on hundreds of library modules, any one of which could have XS-modules involved, therefore any one of which could cause unexpected phone-calls in the night. Hence, build two deployments, one for each target, and separately “test the hell out of them on that very target.” Replicate out to each production system from the appropriate master, then run post-deployment self tests on each production machine (automatically). That is my “wish-list scenario,” and it’s one that I personally would push very hard to achieve. ’Cuz when I’m asleep, (almost...) the only thing I want to wake me up is the dawn.
| |