Rob Withers <rwithers12 at mediaone.net> is widely believed to have written:

> >NOTE NOTE NOTE
> >I don't know whether or not the Mac and Windows makefiles are at the
> >same stepping level. If they are not, it should be within reach of
> >anyone likely to be messing with vm developing to alter the makefiles to
> >find _internal_ plugins in src/vm/intplugins/fooplugin etc rather than
> >just all smooshed into src/vm.
> 
> The windows code, on SF, is currently up to only VMMaker 3.1.3 standards.
> 
> Sure, anyone ought to be able to hand-code the plugins, but what about 
> automatically configuring them, without configure?  VM developer ~= 
> Makefile guru!  Riiight, Tim???  :)
I know that _I'm_ no makefile guru. I don't even play one on the Exstacy
Channel.

Lex's update has made the unix side of things compatible with
vmamker-3-2-v4. The only functional change from 3-1-v3 is that all
plugins configured to be internal plugins are generated into a
subdirectory of src/vm - src/vm/intplugins, so that there is a clean(er)
way to handle complex plugins like mpeg3plugin which benefits from a
local makefile. It also avoids the always-potential and now apparently
actual problem of two plugins having files with the same name.

So, the unix makefiles are updated. I am under the impression that the
windows-via-mingw-tools uses a very similar methodology to build the
actual makefile, so it shouldn't be much of a problem to adapt. Mac (and
presumably MSVC++) project files will need a pretty simple alteration
unless of course they use all-external plugins in which case no effect
will be felt (since the change is only for internal plugins).

If this presents a real problem to anyone, I'm sure it wouldn't take
long to make a VMMaker version that can do it one one for one platform
and the other for some other - but of course they would then have the
above mentioned (potential) problems.

> 
> > > We'll have to come up with some way to distribute snapshots....
> >It has been noted previously that SF makes a frequent (daily?) tarball
> >of all the sources. I wonder if it can be set to produce a tarball of
> >suitably tagged releases so that there is a 'guaranteed' working set?
> 
> That's great, but shouldn't we use the File Release System of Source Forge, 
> to release stable source tarballs?  So the process is
> 
> 1 cvs checkout platform,
> 2 QA it,
> 3 CVS tag it for branching and patching,    (unix-3-2-vmmaker-3-2-4-a1)
> 4 tarball it
> 5 upload it to SF
> 6 define package, define release, then add files to release
> 7 Hey!  It's on the summary page as a released file!  ...
That sounds like a process to me. If that's how it is meant to be done,
we should do it that way.

Sounds to me like we could enhance VMMakerTool to be able to query for
available released packages and then grab one of them or go for
the latest 'live' files. Then one could do things the easy way or the
harder way at will.

I imagine that at some point we will be able to also get the matching
module version for the generated stuff, so that a properly matched set
can the regenerated at any time.

SQcvs and the modules stuff are all just about here, so this shouldn't
be too much in the future. 

> If we could get VMMaker in the update stream, then there would be no need 
> to tag the releases with the VMMaker version.
Let's consider that for the _next_ release.

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: PSM: Print and SMear