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

[Stephan R. <sr...@ev...>]

Tim Rowledge wrote:
> 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.

Yes.

> 
> 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.

Recently I've used Ian's sources to compile a VM. His distribution contains
- and it has to - the VMMaker generated files, too.
My point was to make it possible to the port maintainers to state exactly,
what the 'official' distribution is: without the VMMaker generated sources
you have to generate them: e.g. I wasn't able to generate Ian's choice of
plugins, since some have been missing in my - newer - image.
There is more:
- one maintainer may choose some image version, another one another
  for generating the sources;
- a maintainer may *not* trust some plugins generatable by VMMaker.

I have had the impression, that the port maintainers are very picky
regarding these issues.

> 
> 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.

I'm not so sure here: it also can be a layer of confusion, if I
- check out some SqueakSF platform and cross sources (tagged as dist),
- generate the other sources by VMMaker in my uptodate image,
- compile,
and something doesn't work.

So my question is: how is an 'official' distribution defined?

> 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.

This has been given by e.g. Ian so far.


Greetings,

Stephan

> 
> ti...@su...
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Squeak-VMdev mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squeak-vmdev
> 


-- 
Stephan Rudlof (sr...@ev...)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3