Am 24.09.2013 um 13:56 schrieb "David T. Lewis" lewis@mail.msen.com:

Marcel,

Thanks very much for posting this. It is very helpful to have an up to date recipe for building on Windows.

While the recipe is up to date, I am worried about the recency of the tools itself. The last GCCv3 (ie, gcc 3.4.6) was released in March 2006. Looking at certain Makefiles, they even mention gcc 2.9.5 which is older than 10 years. When reading the compile instructions in the trunk branch, I figure that those are actually more recent and seem (I have not tried it) more fitting for recent compiler. To someone with access to a Windows machine, does compilation with the trunk/platforms/win32 dir work for a Cog build?

Best -Tobias

Dear Eliot, all

Am 24.09.2013 um 20:16 schrieb Eliot Miranda eliot.miranda@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. 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?

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. 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?

Best -Tobias

[1] http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/win32/ [2] http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/win32/HowToBui... [3] https://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-us... [4] I would call the MSYS+MinGW tool-chain 1st level in this case

Am 24.09.2013 um 23:28 schrieb Eliot Miranda eliot.miranda@gmail.com:

Hi Tobias,

On Tue, Sep 24, 2013 at 2:13 PM, Tobias Pape Das.Linux@gmx.de wrote:

...

Dear Eliot, all

Am 24.09.2013 um 20:16 schrieb Eliot Miranda eliot.miranda@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/Autotoo... 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.

Tobias

did you check all the work that igor and esteban did to make sure that all the vms can compile automatically on the build servers?

Stef

On Sep 24, 2013, at 11:13 PM, Tobias Pape Das.Linux@gmx.de wrote:

Dear Eliot, all

Am 24.09.2013 um 20:16 schrieb Eliot Miranda eliot.miranda@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. 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?

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. 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?

Best -Tobias

[1] http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/win32/ [2] http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/win32/HowToBui... [3] https://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-us... [4] I would call the MSYS+MinGW tool-chain 1st level in this case

Dear Stephane, all

Am 25.09.2013 um 08:04 schrieb stephane ducasse stephane.ducasse@gmail.com:

Tobias

did you check all the work that igor and esteban did to make sure that all the vms can compile automatically on the build servers?

No I did check not, but I am actually aware that the Pharo community has spend quite an effort to automatize the VM building process. Kudos to you, Igor, Esteban, Mariano and whoever helped to make that work. I know that the Pharo-flavour of Squeak by default includes Native Boost and constantly tries to sync with Eliot's VMMaker.oscog

So let me try to summarize all existing VM building systems NOT including what goes on in the VMMaker* packages.

• squeak-vm trunk (http://squeakvm.org/svn/squeak/trunk/platforms/): win32: MYSY/MinGW, hand-written ./configure, hand-written templated Makefile unix: CMake, host-compiler (mostly GCC 4) Ian's comment: # Yes, it's true: you can write makefiles in COBOL. carbon (alias Mac OS): Xcode, Errors by default to not be used cocoa (alias iOS, for iPhone/OSX): Xcode RiscOS: Hand-written MakeFile (is this right, Tim?) • squeak-vm/stack-vm/Newspeak-vm cog branch (http://squeakvm.org/svn/squeak/branches/Cog/): win32: cygwin, gcc3, hand-written Makefile, ./mvm shell script osx (using carbon): Xcode, gcc4, clang partly (llvm-gcc?), ./mvm shell script wrapper, ./makevm shell script wrapper unix: autoconf/automake, gcc RiscOS: ? • gitorious-hosted cog-vm (https://gitorious.org/cogvm/blessed) [1] win32: CMake, using MSYS/MinGW osx: CMake, Xcode llvm-gcc not supported, seems to be based on the iOS/cocoa branch unix: CMake, gcc. Cmake-files generated by CMakeVMMaker. clones, use same build system: • pharo-vm (https://gitorious.org/cogvm/pharovm) • oz-vm ((https://gitorious.org/cogvm/ozvm)

That makes, by my counting, 8 distinct build systems. Note that the CMake source for trunk-unix differs from the gitorious hosted one; the trunk-unix one is handwritten by Ian, the gitorious one generated by CMakeVMMaker.

Did I forget some?

Best -Tobias

[1] I think, this is the source you meant, Stephane? PS: The wiki link on http://code.google.com/p/cog/wiki/Guide points nowhere.

On 25-09-2013, at 12:27 AM, Tobias Pape Das.Linux@gmx.de wrote:

So let me try to summarize all existing VM building systems NOT including what goes on in the VMMaker* packages.

• squeak-vm trunk (http://squeakvm.org/svn/squeak/trunk/platforms/): win32: MYSY/MinGW, hand-written ./configure, hand-written templated Makefile unix: CMake, host-compiler (mostly GCC 4) Ian's comment: # Yes, it's true: you can write makefiles in COBOL. carbon (alias Mac OS): Xcode, Errors by default to not be used cocoa (alias iOS, for iPhone/OSX): Xcode RiscOS: Hand-written MakeFile (is this right, Tim?)

Correct. Lovingly hand crafted over decades of carefully trying to keep a minority OS in the game. AIUI, it ought to be possible to make CMake generate an equivalent file even though it doesn't actually run on RISC OS. That would be interesting.

• squeak-vm/stack-vm/Newspeak-vm cog branch (http://squeakvm.org/svn/squeak/branches/Cog/): win32: cygwin, gcc3, hand-written Makefile, ./mvm shell script osx (using carbon): Xcode, gcc4, clang partly (llvm-gcc?), ./mvm shell script wrapper, ./makevm shell script wrapper unix: autoconf/automake, gcc RiscOS: ?

Not yet; I did the fiddly bits to make it run on Raspbian a while back and if anyone out there is sufficiently competent with the auto* stuff that they could add the faster bitblt related stuff, I'd be very happy - I spent far too long and gave up in exhaustion. I could even offer a Pi as a small inducement!

• gitorious-hosted cog-vm (https://gitorious.org/cogvm/blessed) [1] win32: CMake, using MSYS/MinGW osx: CMake, Xcode llvm-gcc not supported, seems to be based on the iOS/cocoa branch unix: CMake, gcc. Cmake-files generated by CMakeVMMaker. clones, use same build system: • pharo-vm (https://gitorious.org/cogvm/pharovm) • oz-vm ((https://gitorious.org/cogvm/ozvm)

So far as I know, no git stuff for RISC OS.

That makes, by my counting, 8 distinct build systems. Note that the CMake source for trunk-unix differs from the gitorious hosted one; the trunk-unix one is handwritten by Ian, the gitorious one generated by CMakeVMMaker.

Did I forget some?

Best -Tobias

[1] I think, this is the source you meant, Stephane? PS: The wiki link on http://code.google.com/p/cog/wiki/Guide points nowhere.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Couldn't find his way through a maze even if the rats helped him.

Hi Stephane

Am 26.09.2013 um 09:05 schrieb stephane ducasse stephane.ducasse@gmail.com:

I do not understand what your objectives are.

This mail just wanted to list the different ways to build a VM that are currently used to make everyone aware of what other parties do. The starting point was that, from simply starting off the squeakvm site, it was a bit tricky to get to compile a VM for on your own. And hence Marcel provided this short tutorial. Eliot just wants to build the Cog VM in a way he has not to put too much effort into learning the build environment (did I understand you the right way, Eliot?).

Our objective was to offer to the community an automatically build set of vms that do not require to be a guru to compile.

And you achieved that! :)

If people want to use our jenkins farm they simply can (just ask for an account and this is it).

Thank you for that great offer!

We will continue improving it and use it to control the complexity. We are working on building a benchmark server. Now if people prefer to do it manually, they also can, we just do not want.

Understandable. There are always some small thing you just want to change, and that is the point where one might want to compile manually. For example, in Marcel's case, he just needed a Windows VM that has no memory-cap of 512 MB, and he just wanted to compile a Cog VM with more Memory. Setting up an automated build for this small task seems overkill to me. However, in most other cases, continuous integration is clearly the way to go!

Best -Tobias

...

If people want to use our jenkins farm they simply can (just ask for an account and this is it).

Thank you for that great offer!

...

We will continue improving it and use it to control the complexity. We are working on building a benchmark server. Now if people prefer to do it manually, they also can, we just do not want.

Understandable. There are always some small thing you just want to change, and that is the point where one might want to compile manually. For example, in Marcel's case, he just needed a Windows VM that has no memory-cap of 512 MB, and he just wanted to compile a Cog VM with more Memory. Setting up an automated build for this small task seems overkill to me.

Tobias my point is that you can - copy a jenkins job :) there is even a button for that :) - second you can just take a process of a build and reuse the CMake generattion made by igor so the process is **documented** and always exercised. So you do not have to set up a jenkins job but you can use the infrastructure put in place. At least I would not try to redo the work done by igor just use/modify/extend it because I prefer to do something else with the time I can gain.

Stef

On 2013-09-30, at 04:56, Tobias Pape Das.Linux@gmx.de wrote:

Am 26.09.2013 um 22:30 schrieb stephane ducasse stephane.ducasse@gmail.com:

...

...

...

If people want to use our jenkins farm they simply can (just ask for an account and this is it).

Thank you for that great offer!

...

We will continue improving it and use it to control the complexity. We are working on building a benchmark server. Now if people prefer to do it manually, they also can, we just do not want.

Understandable. There are always some small thing you just want to change, and that is the point where one might want to compile manually. For example, in Marcel's case, he just needed a Windows VM that has no memory-cap of 512 MB, and he just wanted to compile a Cog VM with more Memory. Setting up an automated build for this small task seems overkill to me.

Tobias my point is that you can

• copy a jenkins job :) there is even a button for that :)

I didn't know that! :)

...

• second you can just take a process of a build and reuse the CMake generattion made by igor so the process is **documented**

and always exercised. So you do not have to set up a jenkins job but you can use the infrastructure put in place. At least I would not try to redo the work done by igor just use/modify/extend it because I prefer to do something else with the time I can gain.

Yes, I understood that. I noticed that you all put effort into this. And I certainly do not want to let that go unnoticed.

As a matter of fact, however, we have currently more than eight ways to build a Squeak/Pharo VM, and for _everyone_ using either of them, there is a high effort learning another one, and one as to make a decision where to put ones effort, just like you said, where to invest ones time. Basically, people like (but not limited to) Eliot or Tim have to decide whether to improve the VM itself or invest time learning a different build system from what they are using now, notwithstanding that a new one even might be better/more efficient/cleaner etc….

Long story short, _I_ think there are too many ways to build a VM for a newbee to decide which to use.

Just to add, http://github.com/pharo-project/pharo-vm now builds completely autonomous under travis: https://travis-ci.org/pharo-project/pharo-vm

that means, this is currently the only build that takes a complete setup into account. Even our current jenkins job rely on a properly setup slave, with travis you have to specify exactly which packages you want.

Just to add, http://github.com/pharo-project/pharo-vm now builds completely autonomous under travis: https://travis-ci.org/pharo-project/pharo-vm

that means, this is currently the only build that takes a complete setup into account. Even our current jenkins job rely on a properly setup slave, with travis you have to specify exactly which packages you want.

Camillo which packages are you talking about? Linux one the slave environment? I love to read https://travis-ci.org/pharo-project/pharo-vm

BTW I could not see GStreamer plugin and I know that annick needs it and we will be looking at it with JB

Stef