"Lex Spoon" <lex at cc.gatech.edu> is widely believed to have written:


> Also, if you have files "intplugins" and "extplugins", the script will
> use those to decide which plugins to compile internally and externally. 
> I haven't heavily tested the internal case, but it looks at least close.
So to make any use of this you'd have to make a subclass of VMMaker that
knows to act quite differently to the 'normal' case; no copying of files
but create these two configuration files....
> 
> By the way, SurfacePlugin has SurfacePlugin.c in the Cross directory. 
> This fouled up my script, which isn't smart enough to deal with files
> being overridden....
... and somehow cope with this.
> 
> 
> 
> > Other platforms do seem
> > to need the files copying, and thus making a special case for the unix
> > seemed pointless at the time. What I'd _really_ have liked is to use
> > links, but not many platforms do links in any sensible manner and there
> > is no Squeak interface to support them anyway.
> 
> I don't understand why any platform would care whether the
> subdirectories were all merged together, but I'll admit, it's not a
> terribly big deal.  The Unix port's makefile can just ignore the copied
> files and use the originals directly, and the other ports can use the
> copied files, and everyone can be happy.
Separating the subdirectories seemed a nice simple way to allow autoconf
to work out which files went where. It also gives some nice human
readable clues about what is going on.

> > The nice part about copying files is that it results in a complete
> > source tree that you can pickle and save for archival purposes or send
> > to somebody else. 
> 
> Good point, that's kinda nice....
I thought so.
> 
> 
> > The baddest part is that it is tempting to edit the
> > files in src/ and recompile rather than editingthe copy in /platforms
> > and rerunning VMMaker. I think there must be some decent heuristic to
> > check the datestamps and warn about overwritten files, maybe even suck
> > them back - but I haven't sat down and worked it through yet. Part of
> > the problem is that old bugbear of poor file access methods.
> 
> You know, make is pretty good about this kind of thing.  Let it know the
> original location, and the copied location, and if the timestamps of the
> original is newer, then do a fresh copy.  Then again, if ou could figure
> a way to tell make where the original file was, then you  wouldn't need
> the copy, anyway.  :)
There's some big problems with this idea. Not all platforms have a
make-analogue that works like on unix. How would one handle the case
where the file in /src is newer than the one in /platforms  - just use
it, warn the user (how?), copy it back (without a warning?). It ought to
be dealt with in the VMMaker/Tool code so that it is properly portable.
One of the 'gleam in the eye' hopes is to avoid using make in any way by
taking advantage of the OSProcess stuff to drive the compiler
explicitly.
> 
> 
> > 
> > > In particular, libmpeg should be shared; it seems
> > > silly to copy all of libmpeg to each platform's MPEGPlugin subdirectory.
> > It is, and it isn't ....
... as in "it is shared" and "it isn't all copied to each platform"

> > PS the explanation of the Cross platform etc is in the help window of
> > the VMMakerTool. Or at least, it should be.
> 
> I was reading the swiki page, and running VMMaker by hand.  I'll have to
> grab VMMakerTool, but the swiki it is on seems to be unavailable right
> now.
>
In that case you must surely be running a very out of date version. The
latest stuff has had VMMakerTool in it for several months now. It is in
http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas/VMMaker-3-1-version3.cs

For the moment I can't help feeling it would be better to just get
VMMaker into use as the general tool and get any wrinkles ironed out and
all the other ports integrated before trying to get too clever for any
particular port. 

 tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- His mind is great at error magnification.