On Thu, Nov 7, 2013 at 3:28 PM, Frank Shearar frank.shearar@gmail.comwrote:
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.
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.
For building deployable packages on existing platforms, Igors words really resonated with me. I'll butt out now. :)
frank
On 7 November 2013 20:45, Chris Muller ma.chris.m@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@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@gmail.com wrote:
Deployment should be regarded a separate problem than building.
On Thu, Nov 7, 2013 at 2:00 PM, tim Rowledge tim@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.