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 with that.
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 -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, as the Vice Squad took his GIFS ..