<div dir="ltr">One approach I haven't seen discussed (so perhaps it has a fatal flaw I don't know about) is for distribution to be done via a tarball that consists of the binary distribution plus a skeleton version control tree - i.e. a source tree checked out the central repo, but with all the files deleted, so just the vcs meta-data. Installation consists of unpacking the tarball, and then (by hand or via a script) issuing the appropriate vcs command to fetch the latest sources, and finally rebuilding the images from source. By including the vcs meta-data in the tarball, you eliminate the failure mode of users not knowing where to get the sources, or getting the wrong version of the sources (although it doesn't eliminate the problem of users getting just the sources and not knowing how to get the binaries, which also used to happen, but that's more manageable).<div><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 30, 2015 at 1:45 PM, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<br>
in 1993, my boss was excited to get a shiny new Solaris box and
asked me to try to get gcc<br>
running on it. gcc sources were freely available, but (unlike
earlier SunOS versions Solaris<br>
did not bundle a C compiler, rendering those sources less useful
than they would otherwise<br>
have been.<br>
<br>
CCL is mostly written in CCL, and you need a recent version of CCL
to bootstrap a new version.<br>
<br>
whether one does<br>
<br>
git clone-or-whatever some-url to get sources<br>
git something different to get platform-specific
binaries into the the same place<br>
<br>
doesn't seem very difficult, but neither did using a vcs and tar
files. I was wrong about that.<div><div><br>
<br>
<br>
<br>
<div>On 11/30/2015 09:47 AM, Dmitry Igrishin
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-11-30 19:20 GMT+03:00 Gary Byers
<span dir="ltr"><<a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span> <br>
<br>
<div>On 11/30/2015 08:29 AM, Stelian Ionescu wrote:<br>
</div>
<blockquote type="cite">
<div>If you want to keep the master copy in SNV and
mirror to git, SubGit can do that but mapping
externals to submodules is not supported: <a href="http://www.subgit.com/remote-book.html" target="_blank"></a><a href="http://www.subgit.com/remote-book.html" target="_blank">http://www.subgit.com/remote-book.html</a> chapter
9.<br>
</div>
<div>If you want to keep the master copy in git and
access it through SVN, Github supports that: <a href="https://help.github.com/articles/support-for-subversion-clients/" target="_blank"></a><a href="https://help.github.com/articles/support-for-subversion-clients/" target="_blank">https://help.github.com/articles/support-for-subversion-clients/</a>.
Again, mapping submodules to externals is not
supported.<br>
</div>
<div> </div>
<div>That said, as far as I understand it, there are
two reasons why binaries are bundles with the
sources:<br>
</div>
<div>1) for easy distribution of released binaries
together with the code so that those who only use
releases can also M-. (or equivalent) without
hassles.<br>
</div>
<div>2) for easy bootstrap because of compiler
and/or ABI(such as fasl format) changes within a
release.</div>
</blockquote>
<br>
</span> Several years ago this was essentially how CCL
was distributed - one checked out sources from CVS and a<br>
a matching tarball via FTP or equivalent, and that was
it. At the time, there were two possible choice of<br>
tarballs., one for 32-bit PPC Linux and another for
32-bit PPC Darwin.</div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
Some of the smartest people that I've ever known were
very confused by this, and I think that having<br>
a single way for users to obtain a consistent set of
sources and binaries is very important. SVN offers<br>
this via "external properties", which are otherwise a
mess. If Git does as well, I have not seen anyone<br>
describe the mechanism. </div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
I don't otherwise care whether one uses "svn co
something" or "git clone something", but I would<br>
not want to expect users to have to revert back to what
didn't work well long ago.</div>
</blockquote>
<div>I don't know about CCL, but the GCC source distribution
comes with a simple</div>
<div>download_prerequisites shell script which downloads via
wget MPFR, GMP, MPC libraries</div>
<div>before building GCC. This works fine for many years.
So, why not use this approach with CCL?</div>
<div>There are "hooks" system in the Git, which are
event-based. It's possible to</div>
<div>run the script for download actual binary files after
git clone or git merge or git pull</div>
<div>operations (post-checkout and post-merge hooks).</div>
</div>
</div>
</div>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Openmcl-devel mailing list<br>
<a href="mailto:Openmcl-devel@clozure.com" target="_blank">Openmcl-devel@clozure.com</a><br>
<a href="https://lists.clozure.com/mailman/listinfo/openmcl-devel" rel="noreferrer" target="_blank">https://lists.clozure.com/mailman/listinfo/openmcl-devel</a><br>
<br></blockquote></div><br></div></div></div></div>