First, it doesn't really need to copy files around, does it? It's no trouble to write the makefile, at least on Unix, to compile files directly from the two different locations.
This may well be true on unix, where the autoconf stuff allows the makefile to be generated depending on the configuration. The hacking about that I did basically made it look for any subdirectory of 'plugins' and compile each one as an external plugin. I imagine one could make it find each 'plugin' sub-dir and then look back across to the platforms/unix/plugins/{matching plugin name} in order to save copying the files.
Yes, this is what I meant. I've uploaded a new copy of SHA now that works like this, i.e., files are pulled directly from platforms/unix and platforms/Cross.
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.
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....
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.
Finally, let's have some space in CVS for files that are shared among multiple platforms.
It's already there; it's called the 'Cross' platform in the tree. sq.h, sqNamedPrims.c etc live there as do assorted plugin files like most of the plugin.h files. Note that files in the Cross platform can be overridden by the ones in the actual platform. As an example, there is a default copy of sqConfig.h that would just make your compiler complain if it were not overwritten. One thing I must try to get around to is making an example platform loosely based on the old sqMacMinimal.c file.
Ah, indeed libmpeg is in there. Silly me.
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....
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. :)
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 ....
I don't understand. The files in platforms/Cross/Mpeg3Plugin *don't* get copied? Or is it only subdirectories that don't get copied? Or what? My picture was that src/Mpeg3Plugin would be the union of:
1. Mpeg3Plugin.[ch], generated from the image 2. platforms/Cross/Mpeg3Plugin/* 2. platforms/foo/Mpeg3Plugin/*
What am I missing?
... and it needs to be added to the SF repository and the unix makefile stuff seems to need some update to make it make it. Lex, didn't you do a hack to makefile.in that made it work for unix? Care to merge it into the SF version of the make files?
I'll do it whenever I find a few spare minutes; it should be pretty close already.... I wouldn't mind being beaten to it, either, by the way. It'll take updating the mkMakefile scripts and re-running them.
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.
-Lex
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 ....
I don't understand. The files in platforms/Cross/Mpeg3Plugin *don't* get copied? Or is it only subdirectories that don't get copied? Or what? My picture was that src/Mpeg3Plugin would be the union of:
- Mpeg3Plugin.[ch], generated from the image
- platforms/Cross/Mpeg3Plugin/*
- platforms/foo/Mpeg3Plugin/*
What am I missing?
Ah, if you look again you should see /Mac OS/plugins/Mpeg3Plugin too. That contains the mac specific changes. The original tree for Mpeg3Plugin was dropped into the VMMaker tree from my archive and was designed to be used by any platform. So some more work is required to break out platform specific features into the subtrees. I think the mac side of that was done a few days back when I added support for building under OS-X.
However reconfiguration for building under Unix and Windows is needed.
& Yes the mpeg3plugin.c file shouldn't really be there and it should be generated each time, versus using my copy from Nov 2000. So I've deleted it.
"Lex Spoon" lex@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.c...
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
squeak-dev@lists.squeakfoundation.org