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

[Eliot Miranda]

On Sun, Apr 24, 2016 at 8:00 AM, Ben Coman <btc at openinworld.com> wrote:

>
> On Sun, Apr 24, 2016 at 3:33 AM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >
> > Hi Tobias,
> >
> > On Sat, Apr 23, 2016 at 10:55 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> >>
> >>
> >>
> >> On 23.04.2016, at 19:44, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >>
> >> >
> >> > Hi Tobias,
> >> >
> >> >> On Apr 23, 2016, at 10:30 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> >> >>
> >> >>
> >> >>
> >> >>> On 23.04.2016, at 19:21, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >> >>>
> >> >>> Hi Fabio,
> >> >>>
> >> >>>  and the "if not, why not?" question is a request for information,
> not an expression of annoyance. Subversion tags update the source in
> checkin.  I remember Igor saying that he couldn't find out how to make gig
> do the same with version numbers (forgive me if my recollection is
> incorrect).  But if git doesn't support this then we need to invent some
> scheme that does work, for example doing two commits, one to generate a
> hash and another to commit a tag.  But we need sensible increment isn't
> version numbers, not stupid hashes.  It has to be a requirement that one
> can tell from the output of
> >> >>>   myvm -version
> >> >>>   yourvm -version
> >> >>> whether the VMs are built from the same or different versions of
> the source and which one is more up-to-date, and that this depends on
> version number, not irrelevancies such as build date.
> >> >>
> >> >> I did such stuff like 4 years ago for self (don't ask why)
> >> >> I changed their whole VM build process to CMake.
> >> >>
> >> >> Here's some parts that vaguely do what you want want:
> >> >>
> >> >> This uses "date" to generate a vm build date (lines 12 and following)
> >> >> and "git" to extract VCS infos (lines 39 and following)
> >> >>
> https://github.com/russellallen/self/blob/master/vm/cmake/configureVmDate.cmake.in
> >> >> (it is namend .in because it gets configured itself from elsewhere)
> >> >>
> >> >> It is clearly possible to switch all the stuff to git and cmake and
> I'd like to see that happen.
> >> >> I would love to have time for that (although it regularly makes me
> angry :D).
> >> >>
> >> >> Best regards
> >> >>   -Tobias
> >> >>
> >> >> PS: Personally (i.e. IMHO), I think that IF we go with cmake, we
> should follo Ians way with
> >> >>   probably some mix of the self vm stuff. It can really work. And it
> can also help us
> >> >>   getting things compiled on MS compilers, btw.
> >> >
> >> > What do you mean by "Ian's way" exactly?  Please describe it.
> >> >
> >> > Things I know:
> >> > - Ian's autoconf code (platforms/unix/conf, the various additional
> snippets that get included when one builds the autoconf support, rather
> than things that get computed at build time) is extremely difficult to work
> with
> >>
> >> Ian's unix conf uses CMake for a while now.
> >> There's no autoconf.
> >> Thers no platforms/unix/conf, neither in
> >>         http://www.squeakvm.org/svn/squeak/trunk/platforms/unix/
> >> nor in
> >>         https://github.com/fniephaus/squeak/tree/master/platforms/unix
> >
> >
> > Yes, I know.  I also know that, for example,
> http://www.squeakvm.org/svn/squeak/trunk/platforms/unix/cmake/Plugins.cmake
> is /not/ easy to work with.  It is essentially impenetrable without
> significant thought.  I will critique fully below.
> >
> >>
> >> So I'm a bit confused about what you refer to.
> >>
> >> > - gmake files work with MS compilers too
> >> >
> >> > I am strongly in favor of gmake files.  It's /much/ easier to work
> with.
> >>
> >> Sorry, i beg to differ.
> >>
> >> >  Please, please, please let's limit the use of cmake to generating a
> config file as I've already discussed.
> >>
> >> you mean gnu make?
> >
> >
> > Yes.  And as examples I invite you to read, for example,
> >
> > http://www.squeakvm.org/svn/squeak/branches/Cog/
> >         build.macos64x64/common/Makefile.app
> >         build.macos64x64/common/Makefile.app.newspeak
> >         build.macos64x64/common/Makefile.app.squeak.cog
> >         build.macos64x64/common/Makefile.flags
> >         build.macos64x64/common/Makefile.plugin
> >         build.macos64x64/common/Makefile.rules
> >         build.macos64x64/common/Makefile.vm
> >
> >         build.macos64x64/pharo.cog.spur/Makefile
> >         build.macos64x64/squeak.cog.spur/Makefile
> >         build.macos64x64/squeak.stack.spur/Makefile
> >
> >         build.win32x86/common/Makefile
> >         build.win32x86/common/Makefile.plugin
> >         build.win32x86/common/Makefile.rules
> >
> >
> > So what are the trade offs?  I'll mark cmake plusses with '+', gmake
> advantages over cmake '-'.
> >
> > + cmake and autoconf include systems for computing a platform-specific
> config.h file from aplatform-independent template that identifies a
> platform's basic facilities, word size, available APIs, etc.  This is of
> value.  I've described earlier in this thread how I want to use this, by
> generating a single copy of the platform-speciifc file per
> platform-specific build directory, where each build directory includes
> several distinct VMs (squeak vs pharo vs newspeak * context vs stack vs cog
> vs sista * v3 vs spur) and a single copy of support libraries such as
> Bochs, Cairo et al.
>
> Naive questions about using a one-time generated config.h...
>   Is this enough to support cross-compilation with cmake itself?
>

I don't know but I would have thought that's orthogonal to the issue/
 Whatever cross compilation scheme is used one has to use the includes for
the platform.  So the config.h would be generated w.r.t. the target
platform not the host.  That's no different.


>   Where in the priorities is cross-compilation?
>

Well, I'd love to use more cross compilation; things would be much faster.
But again it's additional work to get going.  Anyone who gets cross
compilation to any target running on Mac OS X please let me know; I'm
interested.


Of minor concern (because I've no clue of the impact)...  "Rumprun
> unikernels are always cross-compiled. In practical terms, that
> statement means that the compiler will never run on a Rumprun
> unikernel. Instead, the compiler always runs on a build host (e.g. a
> regular Linux/BSD system)."
>
> cheers -ben
>


_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160425/8206ed27/attachment-0001.htm