|
From: Tim R. <ti...@su...> - 2002-08-20 19:27:39
|
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... |