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

 
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

 
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

 

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.