Gcc dependencies in VMMaker

Alejandro F. Reimondo aleReimondo at smalltalking.net
Mon Oct 25 05:05:37 UTC 2004


Hi Tim,
I will try to explain the problems I have had. :-)

I want to do a port to WinCE capable to have Win32
 and WinCE builds in the same machine.
There are shared files between Win32 and WinCE builds.

0.- Running in a clean Squeak3.7.1 image (with VMMaker)
 under windoz...
1.- I created a new folder named WinCE (at the same level
 of Win32) and copy the files there with the same tree of win32.
2.- I have opened the VMMaker tool (a Win32VMMaker
 was instantiated because I was running Squeak in a win* machine)
3.- In the pathToPlatforms code i have placed the same directory as usual.
4.- I pressed the "findPlatform" button and select the WinCE option.
5.- The box with title "Path to generated sources" does NOT change
 to winCE and remain pointing to win32!!!
6.- so I decided to change(edit) the pane contents and change
 path to existing wince directory.
7.- when running the vm generation without any plugin,
 I've found that some files has been deleted (don't know
 which files, but I don't want to try it now :-)
8.- I repeated the procedure restarting from 0 twice...
9.- Then I want to inspect what's going on...

I have found that when I change the last edit box
 by hand  to winCE, whitout having the WinCEVMMaker
 subclass defined, a new instance of VMMaker is created!!!
Yes, when you open the tool a Win32VMMaker is
 created (using #default message, and it is ok for Andreas
 folders shape, and does NOT remove files),
 but when you change the platform name, the #default message
 looks for a class named WinCEVMMaker... and when not found...
 DEFAULTS TO VMMaker!
The new instance of VMMaker delete your files without
 confirmation (as wanted if you are on unix).

The main problem as I saw was the implementation of the stategy for #default
 (and use of subclasification in this case) but found that it is easy to
solve
 my problem creating WinCEVMMaker as a subclass
 of Win32VMMaker to follow the win* rules of building.

Please verify the convenience of creating instances of VMMaker
 (I think that it is not good) and locating behavior for unix
 on a concrete class, making VMMaker abstract and defining
 the main rules, but not instantiable...
Or making a simple preferences model of VMMaker
 for known platforms (using configuration instead of subclassification
 for the little changes of each build preferences).

cheers,
Ale.




----- Original Message ----- 
From: "Tim Rowledge" <tim at sumeru.stanford.edu>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Monday, October 25, 2004 4:07 AM
Subject: Re: Gcc dependencies in VMMaker


"Alejandro F. Reimondo" <aleReimondo at smalltalking.net> wrote:

> Yes, Tim. It is what I have done and all works ok adding the
>  WinCEVMMaker class by hand after seen how VMMaker
>  is been instantiated...

OK, so you have directory platforms/winCE and a class WinCEVMMaker,
which means
a) wince should appear in your menu of chioces for the platform (sounds
like it works)
b) `VMMaker forPlatform: 'winCE'` should result in an instance of
WinCEVMMaker with no plugins configured. Sounds like that bit works too.


> The effect of instantiating a VMMaker instance when I have
>  only put the folder for WinCE, was that the new VMMaker
>  instance created remove the files of directories without
>  any notification
What? This absolutely shouldn't happen. The only likely cause of file
deletion I can see is

a) the method #deleteUnwantedExternalPluginDirectories which is there
to make sure that no longer wanted plugins are removed and the makefile
will not try to build them.  It is only sent by
#generateExternalPlugins though, and no way should it happen just from
changing the platform name.

b) #deleteEntireGeneratedTree which is used only when you press the
'clean out' button. That is intended to remove all the generated files.

> and it was difficult to know what is happening
>  because the instance created when opening
>  is VMMaker tool was a Win32VMMaker...
> (I don´t know if you will understand,... the implicit change
>  of the VMMaker to an instance of a more abstract class
>  without notification is not what I expected to happen).
When you start the tool it makes an instance of a subclass of VMMaker
matched to your platform. So, if you're running on Win32 you'll get a
Win32VMMaker as the default. Similarly on unix you get a UnixVMMaker.

Now an important difference between the Win32VMMaker and all the others
is that, for whatever reason, Andreas wanted to have the >generated<
code placed in the >same< directories as the hand-written platform
code. Take a look at the methods #sourceDirectory, pluginsDirectory etc
in Win32VMMaker and compare to the other versions. An interesting extra
point is that becasue of that the two #delete... methods mentioned
above are null and don't actually delete files! By making WinCEVMMaker
a subclass of Win32VMMaker you are inheriting these issues and that may
be part of the problem.

I've just tried adding a wince platform directory (the menu now has
wince as well as the others) and your changeset. I open a VMMakerTool
and set the platform to wince - the 'path to generated sources' changes
to platforms/wince as expected and no files get deleted or anything
like that. It generates what looks like a reasonable set of files; I
can't test since I don't have wince tools.

Perhaps if you can explain the file tree you have, _exactly_ how yo
used the tool and which files were deleted it might help me visualise
the problem. Right now I'm completely baffled.

tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Money can't buy love. But it CAN rent a very close imitation.




More information about the Squeak-dev mailing list