Just to clarify one thing about fink's setup.
We store all XS modules in versioned subdirectories of /sw/lib/perl5.
The modules which are stored directly in /sw/lib/perl5 are the non-XS
modules, which should work the same across all perl versions.
(This wasn't always true, but we had a big cleanu
On Fri, Nov 14, 2003 at 09:22:47AM -0800, Randal L. Schwartz wrote:
> I am perhaps misremembering then. I recall seeing something on P5P
> that 5.8.2 focussed on being compatible with 5.8.0, and thus breaks
> with 5.8.1 in a few ways. It is still early in the morning here
> though.
You're right.
Michael G Schwern wrote:
On Fri, Nov 14, 2003 at 11:46:12AM -0500, Benjamin Reed wrote:
Was it an apple engineer that did this? Because Perl 5.8.1 final
out-of-the-box defaults to the same thing that's in Apple's perl.
5.8.1 doesn't default to using threads. Maybe you have a different box?
> "Michael" == Michael G Schwern <[EMAIL PROTECTED]> writes:
Michael> I think you're wrong about forward compatibility. The point
Michael> of 5.8.2 was to be compatible with 5.8.0 and 5.8.1. Its
Michael> 5.8.1 that introduced the binary backward compat glitch with
Michael> 5.8.0. Fortunatel
On Fri, Nov 14, 2003 at 11:46:12AM -0500, Benjamin Reed wrote:
> Was it an apple engineer that did this? Because Perl 5.8.1 final
> out-of-the-box defaults to the same thing that's in Apple's perl.
5.8.1 doesn't default to using threads. Maybe you have a different box?
--
Michael G Schwern
On Fri, Nov 14, 2003 at 08:27:37AM -0800, Randal L. Schwartz wrote:
> Not to get too confused, but the Perl 5.8.1 that got included with 10.3
> is a threaded Perl, and a version of threads that is neither backward
> compatible with 5.8.0 (or any prior perl), nor forward compatible
> (it was changed
I agree here and have started on this code, it's just i have two branch
I'm working on already, once they get merged i can start a new branch
ad add auto perl version code.
On 14-Nov-03, at 8:28 AM, Max Horn wrote:
Small side note: how about changing the code to automatically insert
such a dep
Randal L. Schwartz wrote:
Apple won't even be able to upgrade in the future. I wonder who the
Apple bonehead was that decided "threads are better!". Ugh.
Was it an apple engineer that did this? Because Perl 5.8.1 final
out-of-the-box defaults to the same thing that's in Apple's perl. I
don't
> "Max" == Max Horn <[EMAIL PROTECTED]> writes:
Max> Small side note: how about changing the code to automatically insert
Max> such a dependency if the type is "Perl: x.y" ? This way it can't be
Max> forgotten. Would there be any cases where this automatic behavior is
Max> not desirable?
Not
Things seem to work perfectly now.
Thanks a lot Dave for this very clarifying msg.
On Nov 14, 2003, at 2:30 PM, David R. Morrison wrote:
...
The scheme was disrupted somewhat when Apple compiled perl 5.8.1 for
10.3
with a different architecture flag. So for "Type: perl 5.8.1" we now
need
/sw/
[...]
By the way, the versioned perl module packages are supposed to state
a build-time dependency on "perl5.x.y-core", which guarantees that the
appropriate binary is present to compile the package.
Small side note: how about changing the code to automatically insert
such a dependency if the type
11 matches
Mail list logo
