On Sat, Apr 15, 2017 at 4:34 PM, Luke Gorrie <luke@snabb.co> wrote:
> On 15 April 2017 at 10:08, Alistair Grant <akgrant0710@gmail.com> wrote:
>
> Grabbing the source directly from Git is attractive if (a) I know that I am
> choosing a good version and (b) I am able to build it in a good way.
>
> Seems like a workable solution to (a) is to periodically check for a new
> binary release, work out which commit it is based off, and build that. This
> seems fairly reasonable and is probably also possible to automate. (I
> suppose you got the commit-id from --version or from checking Jenkins.)
>
> I see (b) as problematic though. The source tarball releases have a simple
> build procedure ("make") while the Git checkouts require a more involved one
> (bootstrapping the VM from an existing Pharo image.)

A historical perspective...

Prior to this coming Release 6, Pharo had diverged from the parent build system��
used by OpenSmalltalk (nee Squeak-VM)��such that (IIUC) it was driven from the��
Image generating the generated-C-sources��
plus the Cmake configuration.�� I guess this is what you describe as "bootstrap". ��

However for Release 6 onwards, Pharo has returned to the fold and is directly using��
the OpenSmalltalk build system. The OpenSmalltalk build system does not require��
a build to invoke a Smalltalk image, and I notice elsewhere you've seen the ./mvm script. ��
Eliot currently manually updates the checked-in generated-C-sources at times he��
considers them stably generated from VMMaker-Image, although I think I saw
recently some mention of doing CI on each VMMaker check-in.. ����

So the Pharo 5 in-Image CMake generation system is deprecated, and��
I guess there will not be much further development on the Pharo 5 VM.
So I would consider *not* including the bootstrap as part of the nix process
and manually perform the bootstrap per steps 1 to 3 here...
* https://github.com/pharo-project/pharo-vm/tree/5.0-stable
then archive those folders to create your own source-distribution ��

Now it would be good to hear if Pharo might get a Pharo-5-stable-VM��
deployed from OpenSmalltalk?��

cheers -ben



> So I would need to
> revise the nix build scripts quite a bit if I want to build from Git instead
> of the tarballs. However, it seems that on the master branch last week the
> VM build procedure has been reworked so that it is _not_ necessary to run
> the bootstrapping procedure anymore, which sounds great to me, except that I
> understand this new build procedure to be quite bleeding edge and not yet
> documented or used for a binary release (it's not included in the commit
> that you cite above.)
>
> So what to make of all that? Just right now I see only bad alternatives:
> sticking with the source release means not supporting Pharo 5.0, updating
> the build scripts to do bootstrapping takes effort and is already obsoleted
> by changes on the VM master branch, and shipping the VM master branch means
> making a pseudo-release without any QA and potentially causing problems for
> people downstream (there are lots of commits landing on that branch and I
> have no idea which ones are important/stable.)
>
> So the most reasonable course of action from my point of view seems to be to
> sit and wait for a better solution to come along e.g. a new source release
> of the VM or a "blessed" Git commit ID that includes the updated build
> scripts. The downside is that meanwhile NixOS users can't run the 5.0 image.
> Could be that Pharo 6.0 will resolve this and that is fine for me -- but of
> course I'd take a solution sooner if there is a simple one.
>
>