[Vm-dev] svn git bridge? (was: Spur corrupts large images when saving)

Eliot Miranda eliot.miranda at gmail.com
Sat Apr 23 16:44:22 UTC 2016


Hi David, Hi All,


> On Apr 23, 2016, at 8:10 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> 
>> On Sat, Apr 23, 2016 at 02:22:29PM +0200, Nicolas Cellier wrote:
>> 
>> 2016-04-23 13:56 GMT+02:00 Cl??ment Bera <bera.clement at gmail.com>:
>> 
>>> 
>>> On Sat, Apr 23, 2016 at 12:54 PM, Bert Freudenberg <bert at freudenbergs.de>
>>> wrote:
>>> 
>>>> 
>>>> Actually, Fabio did a complete migration while squeakvm.org was out.
>>>> This had a full history of all SVN commits.
>>>> 
>>>> ???Unfortunately??? Ian fixed the server too soon so development continued on
>>>> SVN, so now the git repo is again out-of-date.
>>>> 
>>>> We would need to freeze the SVN, do the migration again, and use git from
>>>> that point on. It would involve a day of downtime, but doing this sooner
>>>> than later would be a good thing.
>> doesn't gitsvn help?
> 
> I have to admit that I did not even know that an active git svn bridge
> was possible. It sounds like this it might be very helpful.
> 
> It would be great to have the advantages of git for development, and
> it could also be helpful to be able to have the squeakvm.org repo updated
> periodically from git. There are portions of the platforms tree that Eliot
> has been able to make identical for oscog and trunk, and this seems like
> a worthwhile effort to continue.
> 
> Another possible advantage is that Ian's cmake build process takes advantage
> of the SVN revision numbering, and it would be good to make sure this stays
> healthy as development proceeds (it's a lot nicer than autotools).
> 
> Eliot, do you have a view on this?

I use svn revision numbering to version stamp my builds.  IMO it's essential that VMs be version stamped with the urls and version numbers of their constituent sources, and that they be built from versioned C that is produced from versioned VMMaker, /not/ that VM source is generated and built without versioning (except for personal use).

If Pharo uses git directly I want platforms/Cross/VM/sqSCCSVersion.h and its dual in (IIRC) platforms/Cross/plugins/sqSCCSPluginVersion.h to be updated so that git version info is included, and /not/ that Pharo takes its own route.  All VMs should understand the -version command line option and display the appropriate information.  (I wrote sqSCCSVersion.h to work with any source code control system, given a little editing, and it was hugely galling that this effort was ignored).

I also did a migration to github but didn't find time to test the subversion bridge.

I really, really want a build system that makes *very* limited use of either autoconf or cmake.  If you look at the Cog build tree I've written gmake makefiles for Windows (adapted from Andreas' originals) and Mac OS X.  These are much more malleable and easy to use than Xcode, autoconfig or cmake (IMNERHO (*)).  Sooner rather than later the UNIX builds should move to this pattern too.  In each build subdirectory is a common directory containing makefiles, eg build.macos32x86/common, and each build directory contains a very simple Makefile that includes the top level Makefile from common, supplying only configuration information.

The only thing missing from this scheme is a cmake or autoconf generated config file, [eg cogConfig.h to avoid conflicting with config.h files generated by cmake or autoconf when building libraries used by plugins, a maddening problem :-) ].  This file should live in the per-platform build directory, eg build.macos32x86/cogConfig.h, and be built once, not on every bloody build, wasting hide amounts of time for people doing VM development (it delays the results from slaves too).

Volunteers welcomed with open arms, and prostrate kissing of feet.  *please* help.  I'm begging.  We need to "be in the same page"; we need to pool our efforts.

For example I would /love/ for someone expert in either autoconf or cmake to write good install instructions for Mac OS X (Xcode includes neither) and code to generate a cogConfig.h that defines things like HAS_POLL HAS_SELECT HAS_OPENGL et al.

I would /love/ for someone to do the same for Windows under Cygwin and/or Windows under mingw.

I would /love/ for someone to work on a 64-bit Spur build for win64.

I would /love/ for someone to organize the build.linux32ARM builds so that the VMs built there run in both Raspberry Pi and Android, and not merely complain to me that they don't and assume I'm an infinitely expandable resource and will get round to it someday even though I have no access to an android device but have three rpis and a b3.

Have I ranted enough now?  Can I go back under my stone now and sulk?

:-)

(*) in my not even remotely humble opinion; I built VMs last night; part of my brain is not in a good mood ;-)

> Dave
> 


More information about the Vm-dev mailing list