<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 30 September 2013 15:53, Camillo Bruni <span dir="ltr"><<a href="mailto:camillobruni@gmail.com" target="_blank">camillobruni@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><br>
On 2013-09-30, at 04:56, Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> wrote:<br>
<br>
> Am 26.09.2013 um 22:30 schrieb stephane ducasse <<a href="mailto:stephane.ducasse@gmail.com">stephane.ducasse@gmail.com</a>>:<br>
><br>
>><br>
>>><br>
>>><br>
>>>> If people want to use our jenkins farm they simply can (just ask for an account and this is it).<br>
>>><br>
>>> Thank you for that great offer!<br>
>>><br>
>>>> We will continue improving it and use it to control the complexity. We are working on building a benchmark server.<br>
>>>> Now if people prefer to do it manually, they also can, we just do not want.<br>
>>><br>
>>> Understandable. There are always some small thing you just want to change,<br>
>>> and that is the point where one might want to compile manually. For<br>
>>> example, in Marcel's case, he just needed a Windows VM that has no<br>
>>> memory-cap of 512 MB, and he just wanted to compile a Cog VM with<br>
>>> more Memory. Setting up an automated build for this small task<br>
>>> seems overkill to me.<br>
>><br>
>> Tobias my point is that you can<br>
>> - copy a jenkins job :) there is even a button for that :)<br>
><br>
> I didn't know that! :)<br>
><br>
>> - second you can just take a process of a build and reuse the CMake generattion made by igor so the process is **documented**<br>
>> and always exercised. So you do not have to set up a jenkins job but you can use the infrastructure put in place.<br>
>> At least I would not try to redo the work done by igor just use/modify/extend it<br>
>> because I prefer to do something else with the time I can gain.<br>
><br>
><br>
> Yes, I understood that. I noticed that you all put effort into this.<br>
> And I certainly do not want to let that go unnoticed.<br>
><br>
> As a matter of fact, however, we have currently more than eight ways<br>
> to build a Squeak/Pharo VM, and for _everyone_ using either of them,<br>
> there is a high effort learning another one, and one as to make<br>
> a decision where to put ones effort, just like you said, where to<br>
> invest ones time.<br>
> Basically, people like (but not limited to) Eliot or Tim have to<br>
> decide whether to improve the VM itself or invest time learning a<br>
> different build system from what they are using now, notwithstanding<br>
> that a new one even might be better/more efficient/cleaner etc….<br>
<br>
> Long story short, _I_ think there are too many ways to build a VM<br>
> for a newbee to decide which to use.<br>
<br>
<br>
Just to add, <a href="http://github.com/pharo-project/pharo-vm" target="_blank">http://github.com/pharo-project/pharo-vm</a> now builds completely<br>
autonomous under travis: <a href="https://travis-ci.org/pharo-project/pharo-vm" target="_blank">https://travis-ci.org/pharo-project/pharo-vm</a><br>
<br>
that means, this is currently the only build that takes a complete setup into<br>
account. Even our current jenkins job rely on a properly setup slave, with<br>
travis you have to specify exactly which packages you want.<br>
<br></blockquote><div> </div></div>Wow. That's very nice readme. You are my hero, Camillo! :)<br><br></div><div class="gmail_extra"><br clear="all"><br>-- <br>Best regards,<br>Igor Stasenko.
</div></div>