Strawberry Perl++

jk2addict on 2006-09-25T14:44:02

Well, today I had enough of AS perl, the various flavors of .NET on my machine, and trying to get Scalar::Util updated and actually running without missing dll errors.

So I uninstalled every ounce of AS perl, and installed Strawberry Perl. It's been smooth compiling ever since.

I'm always late to the party it seems. (I fear change. I shall keep my bushes.)


Thanks!

dagolden on 2006-09-25T15:23:28

That's great news! Welcome to the movement!

Please keep an eye on win32.perl.org for the latest developments. Thanks to some heroic participants (chorny++) Vanilla Perl Problem Modules has become a great source of information for what problems we're still facing. Also #win32 usually has several lurkers who can answer questions.

Re:Thanks!

jk2addict on 2006-09-25T15:29:13

*chuckles*. "see horny"

My concern...

sigzero on 2006-09-25T19:59:23

What about mod_perl and DBD::Oracle? Both of those "just work" with AS Perl. I don't have to set Oracle HOME and I don't have to have the header files. They just install and work for me. Is SP going to be the same?

Re:My concern...

Alias on 2006-09-26T02:39:33

I imagine mod_perl will work when someone cares enough about mod_perl on Win32 to try and make it work.

As for DBD::Oracle, isn't that one a special case? Something about the weird legalities?

Re:My concern...

sigzero on 2006-09-26T16:19:08

My point is that I can use PPM to install platform binaries for both of those modules without any hassle and they work.

Re:My concern...

jk2addict on 2006-09-26T16:26:34

Then I would say you came out on the lucky side of the fence. Most times, I did to using the various repos.

But then there were things like DBD::SQLite and Scalar::Util that caused no end of grief as a ppm (from theoryx) because you never quite know what it decided to compile againste (.NET1, .NET2, VC6, A mix if the lib sniffing code was bonkers).

At least with Strawberry Perl, I have just a tad bit more likelyhood that if will work on any other instance of strawberry perl, rather than preying that my machine happens fo be setup just like the ppm creators machine.

To each their own. PPM got me through many a hard time, but the more windows runtimes I ended up with on my machine, the worse it got.

Plus, the Van/Straw Perl dists are coming out with packagers (Alien::*) I believe.

It won't be Alien::

Alias on 2006-09-26T23:55:20

The Alien:: modules are sort of last resort modules that aren't Win32 specific.

There is a more general problem of integrating with external binary installers.

Part of that the solution to that problem is likely to be something I like to call GNU/Windows, which is likely to be some form of PAR-based binary packing system specifically for Windows.

Most like based on PAR::Repository... but the details are still a bit unclear, as there are more fundamental problems that need to be solved first, like cross-language dependency grammars.

But yes, we'll have some sort of binary packaging system for install non-CPAN deps like imlib and such eventually. I'm not sure that solves DBD::Oracle, but it solves a few other problems.

Re:My concern...

Alias on 2006-09-26T23:49:47

Sure, it's just that you can't use PPM to install anything else... like POE or PPI or a thousand other common modules that are broken because of the PPM build farm's methods.

I start this whole Win32 process in the first place because I got sick of not being able to run my own code on my own laptop.

I'll happily sacrifice mod_perl and DBD::Oracle for a few months in exchange for the ability to be able to install every other "normal" module.

And someone will get to mod_perl et al eventually.

Re:My concern...

sigzero on 2006-09-28T15:04:53

POE is in PPM (theoryx) as is PPI and I haven't had a problem with DBD::SQLite.

Unfortunately I "have to have" mod_perl and DBD::Oracle so I can't sacrifice those at the alter of using SP.

Re:My concern...

Alias on 2006-09-29T05:57:51

So PPM is fine as long as you don't use the repository that comes with PPM.

That, frankly, is really screwy logic.

It should either work out of the box, or it's "broken". There might be workarounds, but I've been through this situation once already with RPM, using workarounds and what have you.

And I'm sick of it.

As for mod_perl and DBD::Oracle, of course you should stick with ANY way you can make it work. And when someone makes those two work, I look forward to seeing you on Strawberry then :)

Re:My concern...

jplindstrom on 2006-09-28T16:19:02

I managed to install DBD::Oracle without problems using AS + Visual Studio. It didn't work with CamelPack and the supplied compiler (MingW?).

I think it's up to DBD::Oracle's code being dependent on VS rather than AS Perl, but I may be mistaken.