Not from Windows to *NIX, you can't just copy binary stuff built on one and expect it to work on the other. Reading OPs post history will reveal current hosting limitations.
| [reply] |
If I'm not mistaken, these build systems rely on the system perl. I never, ever allow anything to come remotely close to my system perl (or python etc).
| [reply] |
I never, ever allow anything to come remotely close to my system perl (or python etc).
Why? If the vendors repo for the system perl has modules, those were compiled and tested with the system perl and just work, just like they would with any custom perl installed with e.g. perlbrew.
For years I have just used the system perl and the system build system to compile and install modules (as *.deb, *.rpm, you name it) not present in the vendor's repo, with no adverse effect to the system perl or the system itself.
The system perl often comes along with patches (Debian for instance has a long patchlist) which are probably optimizing perl for the system at hand. If I were to compile the same perl version with the systems compiler, its libraries and those patches, it would be no different from the system perl.
And there is always local::lib.
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply] |