Auto Joke

[SilverBean]

I'm looking for a little information about these Auto Loader files - if I have the term correct? I'm not seeing this notion discussed in any of the hard documents I have on Perl. I'm guessing there's not much to know. So call it a curiosity. TT seems a little scarce on the subject too.

I have 2 Apache Servers one running under Windows2000(Perl 5.8.7) and the other Fedora Core 6(Perl5.8.8). Just for fun I tried to learn something and downloaded a tar file from cpan. I'm only able to make on my FC. That worked fine and I was able to use the module. The make process seemed to have created 2 files in the auto branch a .bs and .so file. I thought when I removed one or both of these files I got an error about some kind of inherited init deprecated and unble to locate some kind of init.al file.

I'm seeing on the Windows box I've got tons of al files. Since I don't even attempt make on windows I'm guessing the Perl Package Manager created these things as I've installed modules.

Ok so is that all?

Autoload files are .al in Windows, .bs .so in the Linux world?

Now for the joke. I'm guessing the answer is NO to this, but I'll ask anyway. Any chance that I could take these autoload files from Windows onto my Linux box and vice versa? I'm probably looking to take a short cut and just build on one server, but that probably defeats the whole purpose of the make process anyway.

 

[travs69]

I'm not sure about your question on the files but I'm sure the answer to the last question is NO. If it worked that way then you could just download the compiled binary without having to do it your self each time.

The files you get from PPM are pre-compiled binary files that have been tested by activestate. You will notice that the amount of modules available is way less than what is out on cpan.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Travis - Those Who Say It Cannot Be Done Are Usually Interrupted by Someone Else Doing It; Give the wrong symptoms, get the wrong solutions;

 

[SilverBean]

Thanks for your response that's what I wanted to hear.....not.

The real question is probably one of migration and in retro probably should've come from that direction.

Current Day: Local Windows Development System. My live system is a paid for web host and I'm at their mercy as to what modules they offer. Although I am aware of how to specify my own libray path and I do have some modules in use which I absolutely needed.

Future: My Linux box is coming along very nicely I'd like to have that replace my web host by EOY. So I'm looking for an easy way to make all systems the same so the apps have a good chance of continuing to run the same.

Windows=web host, everything thats running on the web host at one time ran on Windows(hopefully no surprises). I was hoping I could not just for 1 file/ 1 module but for a whole folder I could just copy Windowsto new Linux. My "gut" feeling is my web host is Unix I should know for sure. I could "probably" download all the stuff in my own library file and put that on my Linux box. HOWEVER, you confirmed best practice going forward is rebuild or remake all the modules under the new Linux box because I'm betting not only will these be OS specific but OS version specific. Then on top of that this is assuming that the version of Perl is the same which I may not be able to guarantee, kind of sounds like in for a penny in for a pound. I'll wind up going to the current rev of Perl with this effort.

 

[fishiface]

It's perhaps not as bad as it looks: autoload files can be binary or pure perl. Looking through the ones on my web server, the majority of them are pure perl and would allow you to move them between platforms as you wish. The only crucial one with a binary is my database access, which I presume you have sorted already. One or two for which I currently use binaries have pure-perl equivalents.

["]As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.["]
--Maur