Hi Luke,
On Sat, Apr 15, 2017 at 10:34:31AM +0200, Luke Gorrie wrote:
> On 15 April 2017 at 10:08, Alistair Grant <akgrant0...@gmail.com> wrote:
>
> How about trying:
>
> $ git clone https://github.com/pharo-project/pharo-vm.git
> $ cd pharo-vm
> $ git checkout b8ec25a570d7539653e1d793e97609adb509aaed
>
> and build that? It should be the source code for the binary VM on
> get.pharo.org.
>
>
> First, thanks for taking the time to play along with me here, it really helps
> to make sure I don't hold things up due to a misunderstanding.
No problem. My answers below relate to Pharo 6, I haven't tried
building V5 (actually, I'm not sure why you're bothering since 6 should
be out before the end of the month, but that's your choice :-)).
> Grabbing the source directly from Git is attractive if
> (a) I know that I am choosing a good version and
The Pharo50-stable tag points to this commit. Presumably it is kept at
the latest build, but someone else would have to confirm.
If the same isn't already done for V6, I'll certainly be pushing for it
(either a moving tag, or release numbers).
> (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.) 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.
I agree that the build seems a bit messy at the moment. Given how busy
everyone is with the release, I'm keeping quiet for now, but afterwards
I'd like to get my snap package completely automated. Personally, I
think getting the build working reliably from git is worth the trouble
(can test any commit, test patches before submitting pull request, etc).
The (V6) linux install relies on a number of bash scripts to launch pharo
(bin/pharo, bin/pharo-ui and bin/pharo-vm/pharo). How are you producing
these, or are you doing something else?
I'd prefer to get the build using the image working properly as that is
where these scripts are generated (I think).
If you just want to build a single V6 pharo executable (no scripts,
linux 64 bit in the example below):
--
#!/bin/bash
set -e
git clone https://github.com/pharo-project/pharo-vm.git
git checkout <the stable code...>
cd pharo-vm/opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build
./mvm
--
BTW: HEAD is currently eaf13db484ac87720d8454e66b5ce92f51c01036, and my
experience is that it is significantly less stable than the latest
binary, which is from 1c38b03fb043a2962f30f080db5b1292b5b7badb
Cheers,
Alistair
