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

[Ben Coman]

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?
  Where in the priorities is cross-compilation?

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