[VM] [WIN32] [BUG] Adventures in building

Tim Rowledge tim at sumeru.stanford.edu
Tue Feb 19 04:00:07 UTC 2002


Ross Boylan wrote:
> 
> I've tried a naive approach to building on Win32 with MSVC.  Regrettably,
> it doesn't build.  A few of the highlights, with [BUG] marking a few
> seeming smaller bugs.
Good for you for trying!

> 
> I tried to file VMMaker 3.2.5 into Squeak3.3a-4744.image, and almost
> immediately got errors about name redefinitions from other modules.  I
> decided this was a bridge too far, and dropped back to
> Squeak3.2gamma-4743.image.
Yup, I've not even bothered to try a 3.3 image yet since I simply don't
have time to look into the module stuff. 

> 
> I positioned the image above the platforms directory I got from
> sourceforge.  I got the top of the tree, not any tagged versions.  Started
> the VMMaker GUI.
good so far.

> 
> [BUG] The AsynchFilePlugIn plugins refused to move out of the left pane,
> presumably because SF had AsyncFilePlugIn (no h after Async).  Several
> other plugins with no obvious matching names were also left adrift.
It's a fair cop, guv. Spelling differences will inevitably confuse the
evil computer, thus saving the galaxy. I'd say it was an easy fix except
that renaming directories in cvs is tedious. It is quite possible for
there to be 'left over' plugins on various platforms if there is no
apparent support for them; you won't be surprised that TestOSAPlugin is
like this on windows, for example.

> 
> [BUG] Although I changed the name of "Path to Generated sources" in the
> GUI, it used its original name for output.  Or do I need to hit accept
> after editing this?
I'm afraid so, for now. If somebody would like to explain to me how to
make the three editable text fields in VMMakerTool do autoaccept or
whatever, I'd be delighted to hear about it.

> 
> I then edited the .dsp file by hand to give it the correct path to the
> files.  I did not check for a good match between the files listed in the
> .dsp and the actual directory.
> 
> Then I built, using MSVC 6.  Many errors ensued.  Many were caused by the
> following two items:
> 1. sqVirtualMachine.h defines a type "long long".  MSVC hasn't heard of it.
Interesting - another compiler (Acorn didn't like it either) that thinks
ill of it. We had a long debate about this a while back wrt the 64 file
offset stuff.


> 2. attempted use of a #pragma export
Would that be in the plugins code? If so it ought not be problematic,
since you are (duh) exporting those functions.
> 
> Popular warnings:
> Signed/unsigned mismatch
> dangerous type conversions (e.g. double -> float)
You should see the Acorn compiler whine about them. I think it averages
a dozen or more  complaints per line of interp.c!
 
> 
> And quite a few other things.  sqWin32D3D.c was particularly problematic.
> 
> Also, the generated code did not have an intPlugins directory, to my
> surprise.  In fact, it was quite flat; almost everything was under
> vm.  There was a doc and a libmpeg subdirectory.
Current strategy for win32 is _not_ to put internal plugins into
vm/intplugins//fooplugin etc - purely a stopgap measure until somebody
with both the knowledge and the time can modify the makefile(s) to
handle it. Likewise with making them cope with the no-copy policy.

> 
> I'll close with an offer: If someone can tell me what kind of an MSVC
> project file or workspace is required, I might be able to write a VC macro
> that would generate it appropriately (e.g., if the recipe is add all *.c
> file in the main directory).  I've had to muck around with VC a fair amount
> in the past, so I think I know how to do it.
Rob? You've done a bunch of crawling around in this space recently, can
you offer a spec for Ross to work to?


tim




More information about the Squeak-dev mailing list