<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 7, 2013 at 3:28 PM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Wait, why are we talking about deploying a Squeak application here?<br>
We're talking about taking a blank machine and being able to build a<br>
Squeak VM on it.<br>
<br>
Tim's saying that you can't drive a C compiler from within the image<br>
on a machine for which no VM has ever been built, because there is no<br>
VM. ("Machine" here means a machine architecture, rather than, say, a<br>
fresh Ubuntu install.) You need a bootstrap. And<br>
configure/cmake/whatever happens to provide a very easy way to<br>
bootstrap to the first VM that can run an image that _can_ drive a C<br>
compiler to build the next gen VM.<br></blockquote><div><br></div><div>Hm, ok. That's a pretty rarely-occurring event to be putting a lot thought into a framework for. I'm doubtful such a framework would ever "work the first time" on new platforms.</div>
<div><br></div><div>For building deployable packages on existing platforms, Igors words really resonated with me. I'll butt out now. :)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
frank<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 7 November 2013 20:45, Chris Muller <<a href="mailto:ma.chris.m@gmail.com">ma.chris.m@gmail.com</a>> wrote:<br>
> Well, I don't think Tim's point stands anyway. It assumes a blank OS on any<br>
> machine can use configure and cmake, but not squeak. Can windows machines<br>
> run configure and cmake out of the box?<br>
><br>
> Some sort of installation hurdle must be overcome, whether cygwin or<br>
> new-squeak-based-builder.<br>
><br>
> People who are building VM's are a much smaller, more-technically capable<br>
> group than those who need to deploy something (e.g., an application). If<br>
> you design your deployment system for the former, it think it won't be<br>
> useful to the latter.<br>
><br>
><br>
> On Thu, Nov 7, 2013 at 2:36 PM, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>><br>
> wrote:<br>
>><br>
>> But Tim's point still stands, because deployment is the problem you<br>
>> solve after having solved the "build it" problem :)<br>
>><br>
>> frank<br>
>><br>
>> On 7 November 2013 20:13, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
>> > Deployment should be regarded a separate problem than building.<br>
>> ><br>
>> > On Thu, Nov 7, 2013 at 2:00 PM, tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>> wrote:<br>
>> >><br>
>> >><br>
>> >> One important thing to remember is coping with a first build on a new<br>
>> >> machine. Having a squeak app that can drive cc to build a vm would be very<br>
>> >> neat, but if you don't yet have a working vm for a device you could be in<br>
>> >> trouble.<br>
>> >> An advantage of the cmake process is that it bypasses that issue.<br>
>> >> Actually running the configure on the target machine means you get<br>
>> >> (hopefully!) accurate results when querying facilities. There is also some<br>
>> >> benefit in a production environment in being able to pass a 'normal' build<br>
>> >> job to someone else without having to find a squeak buildomatic cognizant<br>
>> >> person.<br>
>> >><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>