[Vm-dev] [HowTo] Compile CogVM for Windows 7 using MinGW/MSYS
Tobias Pape
Das.Linux at gmx.de
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
More information about the Vm-dev
mailing list