Re: [Squeak-VMdev] Re: [SqueakSF] SqeakSF Policy Proposal [was: Re: [VM 3.2-4] build problems, if an acinclude.m4 has been added]

[Tim R. <ti...@su...>]

On Tuesday, August 20, 2002, at 06:51  AM, Stephan Rudlof wrote:
>>>> 0. To get this policy work, there is the need to introduce platform 
>>>> specific
>>>> src trees - e.g. src_unix, src_win, src_mac - for the different ports,
>>>>  which
>>>> contain the 'official' proven sources. Currently there aren't any, 
>>>> but it
>>>> isn't possible to store full ports at SF without them. There has to 
>>>> be one
>>>> source tree for each port, since on each platform there may be a 
>>>> different
>>>> number of plugins or (not so good) a different version of the VM, 
>>>> which are
>>>> working in reality.
>>>
>>
>
>> If I am not mistaken the source tree is partitioned today into one tree
>> for each port and one "Cross" tree with everything in common... Perhaps
>> I misunderstood.
>
> I mean the sources generated by VMMaker here: an 'official' port doesn't
> necessarily contain all possible plugins. And it runs stable with a VM
> generated from whatever Squeak version.
>
> AFAIK VMMaker generated sources are not at SF.
I thought I had very clearly explained how VMMaker works and what I 
anticipated the role of SF/anyotherrepositorywechose would be.

VMMaker generated sources are not expected to be stored on SF; only the 
handwritten code (sqRPCWindow.c etc) should be in that tree. VMM takes the 
tree of files under SF/platforms along with the VM related classes in the 
image and produces a combination ready to build a VM for a particular 
platform and configuration of internal/external/ignored plugins.

One day, I hope that we will be in a position to do automated generated 
sets of sources for each main platform and store them  somewhere sensible 
so that people simply wanting to compile a latest vm can do so without the 
difficulty of having to open a UI tool and press a button or two. Right 
now that isn'tin place but I beleive I have been told it can be done via 
SF related tools.

To determine which plugins work for each platform it is supposed to be 
possible to look at the two directories platforms/platName/plugins and 
platforms/Cross/plugins. If a plugin is in platforms/Cross/plugins and NOT 
in platforms/platName/plugins it had better damn well not have any 
platform dpendencies and must work on any machine. As examples, consider 
MiscPlugin. If a plugin appears in Cross and any platofrm specific place 
then it is supposed to be the case that it requires some platform support.
  Thus if it doesn't appear in your platforms's plugins list it probably 
doesn't work for it.

You can also get a more direct visual answer to the question by opening 
the VMMakerTool and just using the menu in the bottom-left pane to say 
'make all external'. ONLY plugins that the platform can support will be 
moved to the external plugins list. For any particular plugin you can look 
in its class for the messages #requiresPlatformFiles and 
#requiresCrossPlatformFiles etc. Of course, it is conceivable that a 
plugin may have innappropriate implementations of these messages until 
someone discovers and fixes the situation.

Platform specific full source trees should not be maintained in any system 
like SF since it would add another layer of confusion. Tarred up (or 
otherwise bundled) platform trees ready to just compile are another matter 
and have been under consideration for the do-it list for ages.

ti...@su...