help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Help-smalltalk] Building GNU Smalltalk-2.3.5 with MinGW


From: Akeroyd, FA \(Freddie\)
Subject: RE: [Help-smalltalk] Building GNU Smalltalk-2.3.5 with MinGW
Date: Tue, 19 Jun 2007 12:11:30 +0100

Hi,

> You should find out how the problematic path is built (see 
> kernel/MethodInfo.st as well as examples/Publish.st).  You can try

> (AbstractNamespace >> #superspace) methodSourceCode fileName

> to see if the bad path is generated by GNU Smalltalk itself, or rather


This gave

'C:\msys\1.0\home\faa59\Smalltalk_gnu\smalltalk-2.3.5/C:/msys/1.0/home/f
aa59/Smalltalk_gnu/smalltalk-2.3.5/kernel/AbstNamespc.st'

I applied the enclosed patch to File.st and that fixed the "make doc" of
the library, but it is not the end of the story as now rebuilding the
Blox documentation fails with invalid paths. The File.st patch does not
make the methodSourceCode filename above correct, it just allows
Smalltalk to handle it in the library case.

I think the cause of the problem is illustrated by running:

(File fullNameFor: 'c:\some\rubbish\c:\windows') printNl!

Which returns

c:\windows

So (Directory exists: 'c:\some\rubbish\c:\windows') will return true. I
believe the Blox doc issue occurs as the paths being built up in the
baseDirs method of the Package are using "Directory exists:" and thus
getting told incorrect information which they then store. 

The root of the problem probably lies with how to treat c: when it is
detected in the "Directory append:" method as bits of a path are passed
to it. In the above example the first c: should indicate the start an
absolute path, but not the second c: as that then leads to an incorrect
result.

Freddie

Attachment: File.patch
Description: File.patch


reply via email to

[Prev in Thread] Current Thread [Next in Thread]