On Mon, Jul 26, 2010 at 11:21:10AM -0700, Eliot Miranda wrote:
> 
> On Mon, Jul 26, 2010 at 7:13 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> > On Sun, Jul 25, 2010 at 11:01:12PM -0400, Rob Withers wrote:

<snip>

> > > Third, I set self halts in UnixOSProcessPlugin class>>#shouldBeTranslated
> > > and Win32OSProcessPlugin class>>#shouldBeTranslated.   The unix side
> > > eventually calls:
> > >
> > > UnixOSProcessPlugin class>>#isResponsibleForThisPlatform
> > >       "Answer true is this is an instance of the class which is
> > >       responsible for representing
> > >       the OS process for the Squeak VM running on the current platform. A
> > >       false answer is
> > >       usually the result of running the image on a different platform and
> > >       VM.
> > >       Note: Keep this method is sync with OSProcess>>isUnix."
> > >
> > >       | numericOsVersion |
> > >
> > >       ^ (self platformName = 'unix') or:
> > >               [numericOsVersion := self osVersion asInteger ifNil: [0].
> > >               (self platformName = 'Mac OS') and: [numericOsVersion >=
> > >               1000]]
> > >
> > > and this calls:
> > >
> > > OSProcessPlugin class>>#platformName
> > >       "After Squeak version 3.6, #platformName was moved to
> > SmalltalkImage
> > >       "
> > >
> > >       ^ ((Smalltalk classNamed: 'SmalltalkImage')
> > >               ifNil: [^ Smalltalk platformName]) current platformName
> > >
> > > which kills any hope of being a cross-compiled source.
> >
> > No worries there. The C source is not supposed to be cross-compiled. The
> > implementations in Slang/Smalltalk are completely different for Unix and
> > Windows, and the resulting generated code (UnixOSProcessPlugin.c and
> > Win32OSProcessPlugin.c respectively) are completely different as well.
> > When building a VM to run on Unix/Linux/OSX you would be compiling the
> > UnixOSProcessPlugin.c, and when compiling a VM for Windows you would
> > compile Win32OSProcessPlugin.c.
> >
> >
> Cross-compilation is quite separate from generation.  Cog is intentionally
> modified to spit out exactly the same source tree irrespective of platform.

Understood.

>  Needing a different VMMaker generation step for each platform is IMO an
> absurdity.  Whether a plugin is compiled or not then depends on the
> plugins.int and plugins.ext files in each build directory.  So the intent is
> to always spit out the UnixOSProcessPlugin source but only compile it on
> Unix platforms, as selected by plugins.int & plugins.ext.
> 
> I notice I've not included my version of Win32OSProcessPlugin in Cog.  I'll
> rectify that this evening.

I updated OSProcessPlugin, AioPlugin, and XDisplayControlPlugin to work
properly with CrossPlatformVMMaker, and to continue working as before
with the traditional VMMakerTool. This lets CrossPlatformVMMaker produce
the expected sources for Win32OSProcessPlugin and UnixOSProcessPlugin,
and should result in all of these being generated when running Squeak
on Windows.

  www.squeaksource.com/OSProcessPlugin/VMConstruction-Plugins-OSProcessPlugin-dtl.23
  www.squeaksource.com/AioPlugin/VMConstruction-Plugins-AioPlugin-dtl.10
  www.squeaksource.com/XDCP/VMConstruction-Plugins-XDisplayControlPlugin-dtl.8

Dave