<div dir="ltr">The one-step install is not the only issue. We have a self-bootstrapping system. If something breaks and isn't discovered for a while, it's useful to be able to back out of the broken binaries into an earlier version. So while github might not be the right place, the binaries do need to be stored and version-tracked somewhere, in a way that's correlatable with the sources.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 10, 2017 at 10:22 AM, R. Matthew Emerson <span dir="ltr"><<a href="mailto:rme@acm.org" target="_blank">rme@acm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Feb 9, 2017, at 10:48 PM, Ron Garret <<a href="mailto:ron@flownet.com">ron@flownet.com</a>> wrote:<br>
><br>
><br>
> On Feb 9, 2017, at 7:39 PM, R. Matthew Emerson <<a href="mailto:rme@acm.org">rme@acm.org</a>> wrote:<br>
><br>
>> I still have not come up with a brilliant idea to solve the problem of distributing bootstrapping images and interface databases for each of the supported platforms.<br>
><br>
> Can you explain why this is any more of a problem with git than it was with subversion?<br>
<br>
</span>Back when OpenMCL was still in CVS, the way to get a copy was a multi-step process.<br>
<br>
1. get sources (via checkout or via downloading a file, e.g., openmcl-src-0.12.tar.gz)<br>
<br>
2. get interface databases (so that stuff like (#_getpid) will work) by downloading, e.g., openmcl-interfaces-0.4.tar.gz<br>
<br>
3. get bootstrapping image (e.g., openmcl-darwinppc-bin-0.12.<wbr>tar.gz) in order to have a lisp to compile the sources<br>
<br>
When we switched to Subversion, we were able to do two things:<br>
<br>
1. Check in interface databases and bootstrapping binaries<br>
<br>
2. (Ab-)use externals so that it is possible to get sources, interface databases, and bootstrapping binaries in a single command<br>
<br>
Subversion supports binaries fairly well: it can diff them and store deltas. Since it's a centralized system, it doesn't matter if the repository gets large, because checking out a working copy doesn't have to copy the whole repository.<br>
<br>
Git is less suited to storing binaries. It stores them whole (i.e., it doesn't diff them), and since cloning a git repository copies the entire repository, bloating the repository with binaries is a real concern.<br>
<br>
In summary, I think that having a one-command way to get a working CCL is a good feature. I have never liked the way we abuse externals to do that, but the get-ccl-with-one-command feature seemed valuable enough that it was worth it anyway.<br>
<br>
Ideally, I'd like to make it equally easy to get a working CCL when we're on GitHub. That's what I'm trying to figure out how to do. It may be that I can preserve a one-step way to get CCL. Or it might be necessary to a) get source and then b) get interfaces & bootstrapping image. I'm hopeful that GitHub releases will be a good enough tool for this.<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Openmcl-devel mailing list<br>
<a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br>
<a href="https://lists.clozure.com/mailman/listinfo/openmcl-devel" rel="noreferrer" target="_blank">https://lists.clozure.com/<wbr>mailman/listinfo/openmcl-devel</a><br>
</div></div></blockquote></div><br></div>