Hi, there! ---
As Cygwin seems to be not offering gcc-v3 mirrors anymore, here is a step-by-step tutorial to build the CogVM for Windows 7 machines (and later, I suppose) using MSYS: 1. Install the "MinGW Package Download and Installation Tool" > http://www.mingw.org > http://sourceforge.net/projects/mingw/files/Installer/ ! Remember your installation path, e.g. C:\MinGW 2. Run it and install the following classified under "Basic Setup": > msys-base > mingw32-base 3. Run MSYS and setup PATH variable: > EITHER make /mingw/bin accessible (e.g. add symbolic link to /c/MinGW) > OR add /c/MinGW/bin to PATH (=> my choice) 4. Install or downgrade the following packages via MSYS (close the MinGW installation tool first). If you downgrade, you may have to uninstall the current version first: > DOWN: mingw32-binutils 2.22-1 (fix windres.exe behavior) > NEW: mingw32-gcc-v3-core 3.4.5-20060117-3 > NEW: mingw32-gcc-v3-g++ 3.4.5-20060117-3 > DOWN: mingw32-mingwrt 3.20-2 (needed for linking gcc-v3 object files) > DOWN: mingw32-w32api 3.17-2 (needed for linking gcc-v3 object files) ! MSYS command example: "mingw-get --install reinstall binutils=2.22-1" 5. Checkout SVN repository with CogVM source > http://squeakvm.org/svn/squeak/branches/Cog ! Remember your checkout path, e.g. C:\Tools\cogvm 6. Adapt /c/Tools/cogvm/cygwinbuild/Makefile > Adapt -L option for LDFLAGS and CONSOLELDFLAGS to your MSYS environment > Maybe exchange --export-dynamic with --export-all-symbols 7. Adapt /c/Tools/cogvm/cygwinbuild/plugins.ext > Remove BochsIA32Plugin because it will not build 8. Adapt /c/Tools/cogvm/cygwinbuild/Squeak.rc if needed, e.g.: > Use custom icons and descriptions to identify your build artifact later on :) 9. Run the script ./c/Tools/cogvm/cygwinbuild/mvm > chmod +x it if needed It should build fine with the results added to cygwinbuild/build*. Best, Marcel |
Marcel, Thanks very much for posting this. It is very helpful to have an up to date recipe for building on Windows. Dave On Tue, Sep 24, 2013 at 12:43:27AM -0700, Marcel Taeumel wrote: > > Hi, there! --- > > As Cygwin seems to be not offering gcc-v3 mirrors anymore, here is a > step-by-step tutorial to build the CogVM for Windows 7 machines (and later, > I suppose) using MSYS: > > 1. Install the "MinGW Package Download and Installation Tool" > > http://www.mingw.org > > http://sourceforge.net/projects/mingw/files/Installer/ > ! Remember your installation path, e.g. C:\MinGW > 2. Run it and install the following classified under "Basic Setup": > > msys-base > > mingw32-base > 3. Run MSYS and setup PATH variable: > > EITHER make /mingw/bin accessible (e.g. add symbolic link to /c/MinGW) > > OR add /c/MinGW/bin to PATH (=> my choice) > 4. Install or downgrade the following packages via MSYS (close the MinGW > installation tool first). If you downgrade, you may have to uninstall the > current version first: > > DOWN: mingw32-binutils 2.22-1 (fix windres.exe behavior) > > NEW: mingw32-gcc-v3-core 3.4.5-20060117-3 > > NEW: mingw32-gcc-v3-g++ 3.4.5-20060117-3 > > DOWN: mingw32-mingwrt 3.20-2 (needed for linking gcc-v3 object files) > > DOWN: mingw32-w32api 3.17-2 (needed for linking gcc-v3 object files) > ! MSYS command example: "mingw-get --install reinstall binutils=2.22-1" > 5. Checkout SVN repository with CogVM source > > http://squeakvm.org/svn/squeak/branches/Cog > ! Remember your checkout path, e.g. C:\Tools\cogvm > 6. Adapt /c/Tools/cogvm/cygwinbuild/Makefile > > Adapt -L option for LDFLAGS and CONSOLELDFLAGS to your MSYS environment > > Maybe exchange --export-dynamic with --export-all-symbols > 7. Adapt /c/Tools/cogvm/cygwinbuild/plugins.ext > > Remove BochsIA32Plugin because it will not build > 8. Adapt /c/Tools/cogvm/cygwinbuild/Squeak.rc if needed, e.g.: > > Use custom icons and descriptions to identify your build artifact > later on :) > 9. Run the script ./c/Tools/cogvm/cygwinbuild/mvm > > chmod +x it if needed > > It should build fine with the results added to cygwinbuild/build*. > > Best, > Marcel > > > > -- > View this message in context: http://forum.world.st/HowTo-Compile-CogVM-for-Windows-7-using-MinGW-MSYS-tp4709963.html > Sent from the Squeak VM mailing list archive at Nabble.com. |
Am 24.09.2013 um 13:56 schrieb "David T. Lewis" <[hidden email]>: > > 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 signature.asc (210 bytes) Download Attachment |
In reply to this post by marcel.taeumel (old)
Thanks Marcel!! Can I fold this into my makefiles? On Tue, Sep 24, 2013 at 12:43 AM, Marcel Taeumel <[hidden email]> wrote:
best, Eliot
|
Dear Eliot, all Am 24.09.2013 um 20:16 schrieb Eliot Miranda <[hidden email]>: > 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/HowToBuild.txt?revision=2612&view=markup [3] https://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-using-git-and-cmakevmmaker/ [4] I would call the MSYS+MinGW tool-chain 1st level in this case signature.asc (210 bytes) Download Attachment |
Hi Tobias, On Tue, Sep 24, 2013 at 2:13 PM, Tobias Pape <[hidden email]> wrote:
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. 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...). 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.
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 Ian apparently has done some tweaks to the build system Not carefully. I try to merge when I see relevant changes going into trunk, but I've probably missed a few. Please do not regard me as a show stopper or „Spaßbremse“, +1000. But I need help. I don't have time to attend to this now :-( I think Mariano did a good job for an introduction Onwards and upwards ;-) 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 ;-)
Best best, Eliot
|
Am 24.09.2013 um 23:28 schrieb Eliot Miranda <[hidden email]>: > Hi Tobias, > > On Tue, Sep 24, 2013 at 2:13 PM, Tobias Pape <[hidden email]> wrote: > >> >> Dear Eliot, all >> >> Am 24.09.2013 um 20:16 schrieb Eliot Miranda <[hidden email]>: >> >>> 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. > 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 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. > >> 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 ;-) > 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. signature.asc (210 bytes) Download Attachment |
On 24-09-2013, at 3:34 PM, Tobias Pape <[hidden email]> wrote: > > 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]) There is also a very good reason for wishing to see cmake used for eliot's codetree - the plain interp tree uses it. A replacement of auto* by cmake would be a non-trivial step towards getting the two trees closer together. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Oxymorons: Software documentation |
In reply to this post by Tobias Pape
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 <[hidden email]> wrote: > Dear Eliot, all > > Am 24.09.2013 um 20:16 schrieb Eliot Miranda <[hidden email]>: > >> 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/HowToBuild.txt?revision=2612&view=markup > [3] https://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-using-git-and-cmakevmmaker/ > [4] I would call the MSYS+MinGW tool-chain 1st level in this case |
yes, we are using Win7 and MSYS since... well, since win7 is out. But of course, that means use cmake and CMakeMaker. Esteban On Sep 25, 2013, at 8:04 AM, stephane ducasse <[hidden email]> wrote: > > 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 <[hidden email]> wrote: > >> Dear Eliot, all >> >> Am 24.09.2013 um 20:16 schrieb Eliot Miranda <[hidden email]>: >> >>> 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/HowToBuild.txt?revision=2612&view=markup >> [3] https://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-using-git-and-cmakevmmaker/ >> [4] I would call the MSYS+MinGW tool-chain 1st level in this case > |
In reply to this post by stephane ducasse-2
Dear Stephane, all Am 25.09.2013 um 08:04 schrieb stephane ducasse <[hidden email]>: > > 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. signature.asc (210 bytes) Download Attachment |
Am 25.09.2013 um 09:27 schrieb Tobias Pape <[hidden email]>: > Dear Stephane, all > > Am 25.09.2013 um 08:04 schrieb stephane ducasse <[hidden email]>: > >> >> 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 […] signature.asc (210 bytes) Download Attachment |
In reply to this post by Tobias Pape
On 25-09-2013, at 12:27 AM, Tobias Pape <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Couldn't find his way through a maze even if the rats helped him. |
In reply to this post by Tobias Pape
I do not understand what your objectives are. Our objective was to offer to the community an automatically build set of vms that do not require to be a guru to compile. If people want to use our jenkins farm they simply can (just ask for an account and this is it). 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. Stef > Dear Stephane, all > > Am 25.09.2013 um 08:04 schrieb stephane ducasse <[hidden email]>: > >> >> 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. |
Hi Stephane Am 26.09.2013 um 09:05 schrieb stephane ducasse <[hidden email]>: > > 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 signature.asc (210 bytes) Download Attachment |
On 26 September 2013 10:06, Tobias Pape <[hidden email]> wrote:
Ah, this one. Sounds familiar. I was also arguing that everyone should be able to do it by building own VM, but people wanted simpler solution, so we ended up adding new option in .ini file: like that you don't have to recompile the VM if you need different limit. Btw, we (pharo developers) moved pharo vm sources to github (not gitorious anymore), not long ago, and we will continue development there [2]. Main difference is: merging .st sources with C sources, so all VM sources now is in single repository, and no need to mess with MC packages etc. It also simplifies a lot the commit & build process. [1] [2] https://github.com/pharo-project/pharo-vm Best -- Best regards, Igor Stasenko. |
In reply to this post by Tobias Pape
> > >> 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 |
Am 26.09.2013 um 22:30 schrieb stephane ducasse <[hidden email]>: > >> >> >>> 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. 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. Best -Tobias signature.asc (210 bytes) Download Attachment |
On 2013-09-30, at 04:56, Tobias Pape <[hidden email]> wrote: > Am 26.09.2013 um 22:30 schrieb stephane ducasse <[hidden email]>: > >> >>> >>> >>>> 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. signature.asc (457 bytes) Download Attachment |
On 30 September 2013 15:53, Camillo Bruni <[hidden email]> wrote: Wow. That's very nice readme. You are my hero, Camillo! :)
-- Best regards, Igor Stasenko. |
Free forum by Nabble | Edit this page |