[Vm-dev] [HowTo] Compile CogVM for Windows 7 using MinGW/MSYS

Tue Sep 24 22:34:11 UTC 2013

Am 24.09.2013 um 23:28 schrieb Eliot Miranda <eliot.miranda at gmail.com>:

> Hi Tobias,
> 
> On Tue, Sep 24, 2013 at 2:13 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
> 
>> 
>> Dear Eliot, all
>> 
>> Am 24.09.2013 um 20:16 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>> 
>>> Thanks Marcel!!  Can I fold this into my makefiles?
>> 
>> Is gcc 3 really necessary for Cog?  “yes” clearly
>> is a proper answer, but last year, as I had to fiddle
>> with the Self VM and make it compile, even Old gcc4
>> were a pain.
>> 
> 
> All I wanted to do was to thank Marcel for his advice on setting up a
> functional build environment, and include whatever parts of that were
> relevant.  

Yes. I should make a pause to emphasize this, too. mea culpa.

> I am actually trying to use gcc 4 for cygwin but this is on the
> back burner because the win32api headers in latest cygwin releases were
> damaged when last I tried to build (it appears someone has supplied the
> 64-bit version in the 32-bit context, grr...).

Sounds painful.

>  I tried to set up the
> Makefile to select either gcc3 or gcc4 depending on cygwin version.  I was
> doing this primarily to build a correct SqueakSSL plugin, which would not
> build with the older win32 api in the older gcc3-based cygwin I've been
> using since 2009.  Alas I failed to build using a more up-to-date cygwin.
> So you can imagine I was very pleased to see that Marcel had made progress.

Yes, I imagine. I was pretty excited, too, when he showed me that it works ;)

> 
> So IMO, no gcc 3 should *not* be necessary to build Cog.  But a functional
> build environment is needed, and right now I don't have a funcitonal
> gcc4-based build environment :-(
> 
> Anyone who wants to try and fix this is very welcome.  I can supply them
> with the Makefile that selects the appropriate gcc version.  So far I have
> this in my not-yet-checked-in experimental Makefile:
> 
> # C compiler settings (gcc-3.4.4 cygwin 1.5.25(0.156/4/2) vs gcc-4.5.2
> 1.7.17(0.262/5/3))
> # determine cygwin version using uname -r
> #
> # determine "old" (eg 1.5.25(0.156/4/2)) or "new" cygwin (eg
> 1.7.17(0.262/5/3))
> ifeq ($(shell ls
> /usr/bin/i686-pc-mingw32-gcc.exe),/usr/bin/i686-pc-mingw32-gcc.exe)
> NEWMGW=true
> endif
> 
> ifdef NEWMGW
> CC:=i686-pc-mingw32-gcc
> else
> CC:=gcc
> endif

When I sat down with Marcel, we were at this point, too.
It turned out, however, that the i686-pc-mingw32-gcc was
not able to compile and link (or better, find the right paths
and includes) the whole codebase. Marcel found a package
providing an i686-w64-mingw32-gcc, which got further but
eventually failed, too.

> 
>  Ian apparently has done some tweaks to the build system
>> for the win32 branch[1]. It also uses MSYS and MinGW but
>> probably more recent gcc'en (but I'm not sure)[2].
>>  Just out of curiosity, have you sync'ed the cog-branch
>> platform dir after the initial branching?
>> 
> 
> Not carefully.  I try to merge when I see relevant changes going into
> trunk, but I've probably missed a few.

well, the whole cygwinbuild dir is gone and replaced…

> 
>> Please do not regard me as a show stopper or „Spaßbremse“,
>> but I figure, that the entry barrier to work with the
>> Squeak VM or Cog is quite high, even if you don't want
>> touch the interpreter/jit at all. We should make it
>> more approachable.
>> 
> 
> +1000.  But I need help.  I don't have time to attend to this now :-(

If Marcel has a VM request again, and we have some time,
we probably can figure out something, but alas, I cannot
promis; university wants its time :)

> 
> 
> 
>>  I think Mariano did a good job for an introduction
>> to building a Squeak/Cog VM[3], But his 2nd-level
>> tool-chain (sources from gitorious+CMake via CMakeVMMaker)[4]
>> seems vastly different from the current Makefile-based
>> approach, but apparently, the CMake toolchain can make use
>> of more recent compilers.
>> 
>> Where are we headed?
>> 
> 
> Onwards and upwards ;-)

We better should.

>  Personally I hate both autoconf and CMake, but
> better the devil you know, and have hence stuck with autoconf on unix.  On
> Mac & cygwin I use ungenerated makefiles.  I'm open to change but I don't
> want to do the work.  If someone can help produce functional build
> environments I'll gladly try them out and fold them back in if they work.
> But they must work for the Squeak VM, the Squeak MT VM and the Newspeak
> VM.  That's what I build across three platforms right now and I don't want
> to waste the cycles trying to get new stuff to work with no guarantee of
> success...  Call me a cynic ;-)

Not cynic, but more pragmatic.
But I think we will eventually reach a status of discomfort with either
choices we face (think gcc3 vs gcc4 and so on) and then, we as a community
have to decide.
  As for cmake vs autoconf vs…, when I worked on compiling the Self VM[1],
I looked into several build systems. They all have their odds and ends,
but in the end I figured, that they all need external tools apart from 
make, and cross-platform make is really painful.
In the end I chose cmake because
  • learning a new language is not worse than for automake/conf/tools[2],
    gyp[3], or qmake[4] (haven't looked at tup[5])
  • CMake can generate files for your preferred native Build environment
    (Xcode on OSX, VStudio on Win32, Eclipse…) and pure Makefiles, too.
  • cmake allows for integration with pkg-config to detect availability
    of libraries.
  • cmake can be used with GUIs/CUIs to pre-select configuration schemes
    (eg, shall I build a Cog/Stack/Interpreter? MT/non-MT? Pharo/Squeak-
     branded? Newspeak instruction set?)
This is no advertising but my findings of that time.
Either choice will fit me.

HTH

Best
	-Tobias

[1] I wrote about my findings of that time on http://blog.selflanguage.org/
    My CMake stuff for self went here: https://github.com/krono/self/tree/cmake/vm/cmake
[2] See 
    https://www.gnu.org/savannah-checkouts/gnu/automake/manual/html_node/Autotools-Introduction.html
    https://www.gnu.org/software/automake/
    I personally think the hodgepodge of autoconf syntax, automake syntax, and
    loads of template files, and M4, make this choice as approachable as
    the Mt Everest for a 5 year old
[3] See https://code.google.com/p/gyp/
    Used by Chromium and v8 to overcome certain problems the authors had with cmake.
    The syntax (https://code.google.com/p/gyp/wiki/GypLanguageSpecification) essentially
    is JSON with special keyword (or s-expressions, if you want)
[4] http://qt-project.org/wiki/Category:Tools::qmake, 
    http://qt-project.org/doc/qt-5.0/qtdoc/qmake-manual.html
    It bears resemblance with cmake but really makes only sense when using Qt.
[5] http://gittup.org/tup/ I don't know it but Chis Double (http://double.co.nz/, 
    http://bluishcoder.co.nz/) does.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130925/d5e585be/signature.pgp