Brian,
From: Brian Ingerson [mailto:[EMAIL PROTECTED]]
>
> Garrett Goebel wrote:
> >
> > 1) Inline is case-sensative with filenames whereas Win32 is not.
> >
> > If you compile a simple inline c package "Foo" and rename
> > it "FOO", inline will fail with "Had problems bootstrapping
> > Inline module FOO"... errors
>
> Is this causing problems? Why are you renaming things and expecting it
> to work? I would consider this low priority, if even an Inline problem
> at all.
Oh it isn't causing me problems. I just found it and distinguished it as a
separate issue from #2 below. It should at least be an errata. When the MD5
checksum hasn't changed, and the case-insensative -f $o->{location} == 1,
case-sensative access to symbols in the DLL will fail.
I'm guessing you'd have to change Inline.pm to do a case-sensative
File::Find or readdir comparison of the $o->{location} instead of if (-f
$o->{location}) to fix the bug. But as you said, it's a low priority bug. If
time presents itself, I'll try to work up a patch for you.
> > 2) There seems to be a maximum length limitation on package names
> >
> > OK: package abcdefghijklmnopqrstuvwxyz;
> > NOT OK: package abcdefghijklmnopqrstuvwxyza;
> > OK: package Win32::Struct::Abcdefghijklmnopq;
> > NOT OK: package Win32::Struct::Abcdefghijklmnopqr;
> >
> > This may have something to do with the maximum size of a
> > shell command using command.com. Which under WinNT4.0 is
> > 127 characters. Cmd.exe on the other hand does not appear
> > to have an easily reachable limit. Anyone know what it is?
>
> I expect most of these length problems to disappear when I
> implement the new object naming scheme. Stay tuned...
Me too. Though you may want to throw a note in the errata section anyway
just so people can't say you didn't warn 'em.
Garrett
