[squeak-dev] re: A Bounty for CMake-ifying stack/Cog vm build process

Frank Shearar frank.shearar at gmail.com
Thu Nov 7 21:28:36 UTC 2013


Wait, why are we talking about deploying a Squeak application here?
We're talking about taking a blank machine and being able to build a
Squeak VM on it.

Tim's saying that you can't drive a C compiler from within the image
on a machine for which no VM has ever been built, because there is no
VM. ("Machine" here means a machine architecture, rather than, say, a
fresh Ubuntu install.) You need a bootstrap. And
configure/cmake/whatever happens to provide a very easy way to
bootstrap to the first VM that can run an image that _can_ drive a C
compiler to build the next gen VM.

frank

On 7 November 2013 20:45, Chris Muller <ma.chris.m at gmail.com> wrote:
> Well, I don't think Tim's point stands anyway.  It assumes a blank OS on any
> machine can use configure and cmake, but not squeak.  Can windows machines
> run configure and cmake out of the box?
>
> Some sort of installation hurdle must be overcome, whether cygwin or
> new-squeak-based-builder.
>
> People who are building VM's are a much smaller, more-technically capable
> group than those who need to deploy something (e.g., an application).  If
> you design your deployment system for the former, it think it won't be
> useful to the latter.
>
>
> On Thu, Nov 7, 2013 at 2:36 PM, Frank Shearar <frank.shearar at gmail.com>
> wrote:
>>
>> But Tim's point still stands, because deployment is the problem you
>> solve after having solved the "build it" problem :)
>>
>> frank
>>
>> On 7 November 2013 20:13, Chris Muller <asqueaker at gmail.com> wrote:
>> > Deployment should be regarded a separate problem than building.
>> >
>> > On Thu, Nov 7, 2013 at 2:00 PM, tim Rowledge <tim at rowledge.org> wrote:
>> >>
>> >>
>> >> One important thing to remember is coping with a first build on a new
>> >> machine. Having a squeak app that can drive cc to build a vm would be very
>> >> neat, but if you don't yet have a working vm for a device you could be in
>> >> trouble.
>> >> An advantage of the cmake process is that it bypasses that issue.
>> >> Actually running the configure on the target machine means you get
>> >> (hopefully!) accurate results when querying facilities. There is also some
>> >> benefit in a production environment in being able to pass a 'normal' build
>> >> job to someone else without having to find a squeak buildomatic cognizant
>> >> person.
>> >>
>> >
>
>


More information about the Squeak-dev mailing list