[Vm-dev] VMMaker updating: Mantis 6828 and the future of copying
tim at rowledge.org
Tue May 27 20:54:22 UTC 2008
On 27-May-08, at 12:54 PM, Bert Freudenberg wrote:
> On 27.05.2008, at 20:33, tim Rowledge wrote:
>> OK, two issues here, one shortterm, one longer term.
>> a) in mantis 6828 Dave Lewis proposes some changes to fix some
>> 64bitness issues. They look good to me and he added tests. However
>> I'm not responsible for unix vms and I'm not about to commit those
>> changes. Somebody else will have to handle that and close the
>> mantis report etc.
> Ian added Dave's VMMaker patches already, so I assume he'd merge
> these things, too. OTOH if we were to drop the FileCopyPlugin, we
> would not need to update it, right?
Correct but I don't see us getting all the work to add links etc done
any time soon and so the old plugin needs to work.
>> b) I'm reasonably sure that all the platforms we are interested in
>> now support file links of some sort. File copying (and the vile
>> FileCopyPlugin may it be cursed to the bottom of the pits of Vista)
>> was only ever used because we had no linking available. Eliot will
>> cheerfully (I'm sure) rabbit on for hours about how we used to
>> handle things in the brouhaha source tree, where sets of files for
>> particular platforms were assembled by links from the assorted
>> subsystems, thus making it easy to make. Or even nmake.
>> It would be really nice to agree a path towards a brighter future
>> where VMMaker doesn't have to copy files and worry about damned
>> permissions/attributes/flavours/whatever. Thoughts please?
> Bury it I'd say. Who was using it anyway?
It's been a while since I thought about this stuff. IIRC the copying
was originally intended to allow the assembly of a customised
directory so that the automake stuff could then create the right VM
based on the list of plugins etc that were in the directory. It might
have been possible to write out a config file for automake as an
alternative but then you'd have to do something similar for nmake
(what was in use for windows at the time) and CodeWorrier (what was in
use for Macs) and so on. Things are quite a lot different these days
and maybe we should try to take advantage of any improvements over the
last 10 years.
Part of the complication was that people wanted to be able to make
custom combinations of internal and external plugins. I doubt that has
been used all that much. Personally I think that all plugins should be
external and that the platform should have a sensible way of coping
> Btw, I think it would be nice to revive
Yes, it would.
> Also, some idea about how to handle plugins development-wise would
> be nice. The unix VM now ships several non-default plugins (DBus,
> GStreamer, Rome, maybe more) that one has to download from different
> repositories. Maybe the source for those should be added to the
> VMMaker repo? Or added to SVN? Maybe even a whole VMMaker image?
I don't know how we should handle plugins that need code from other
projects. Suggestions welcome.
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
"Bother" said Pooh, as the Vice Squad took his GIFS ..
More information about the Vm-dev