<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 10 July 2015 at 14:45, Johannes Pfau via D.gnu <span dir="ltr"><<a href="mailto:d.gnu@puremagic.com" target="_blank">d.gnu@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I thinks it's time to push some new binary releases to <a href="http://gdcproject.org" rel="noreferrer" target="_blank">gdcproject.org</a> (gcc-5, intrinsics for checkedint, ...). We should first get some structure into our download archive though: <a href="ftp://ftp.gdcproject.org/binaries/" rel="noreferrer" target="_blank">ftp://ftp.gdcproject.org/binaries/</a><br>
<br>
The first question is whether we can break old download links. I've hardcoded one or two toolchain URLs in the build scripts, but that could be changed easily.<br>
<br>
<br></blockquote><div><br></div><div>I think we can break anything that isn't a short name (should be a symlink on the server).  We need to keep at least these for Travis to continue working.<br><br><a href="http://ftp.digitalmars.com/LATEST_GDC">http://ftp.digitalmars.com/LATEST_GDC</a><br><br>By all means, we can raise a PR with Travis to move it elsewhere, then remove the rest of the old structure later.<br><br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Another question is how exactly the new directory layout should look like. I think we definitely need host folders as a top-level structure:<br>
<br>
/binaries<br>
 |- x86_64-linux-gnu<br>
 |- x86_64-w64-mingw32<br>
 |- arm-linux-gnueabi<br>
<br>
Do we want to have the target as a directory? GCC version? Frontend version?<br>
I think the frontend version is usually more important for users than gcc version. So if we don't use the GCC version we still have two options. dmdversion/target or target/dmdversion:<br>
<br>
/binaries<br>
 |- x86_64-linux-gnu<br>
 |  |- 2.061<br>
 |  |  |- x86_64-w64-mingw32<br>
 |  |  |  |- x86_64-w64-mingw32_2.061.2_gcc4.8.2_AAAA_20140430.tar.xz<br>
 |  |  |  |- x86_64-w64-mingw32_2.061.2_gcc4.8.2_BBBB_20140430.tar.xz<br>
 |  |  |- arm-linux-gnueabi<br>
 |  |- 2.062<br>
 |- x86_64-w64-mingw32<br>
 |- arm-linux-gnueabi<br>
<br>
Another question: DMD frontend sub-releases in one folder? (2.061|2.061.1|2.061.2)<br>
<br></blockquote><div><br></div><div>I think GCC releases should take precedence over D Frontend and architecture IMO.  As that is the most recognisable (and important) aspect of the name.<br><br></div><div>eg:<br><br>/binaries<br></div><div>
 |- 4.8.4<br></div><div>
 |  |- x86_64-linux-gnu<br>
 |  |  |- gdc-4.8.4+2.061.2.tar.xz<br> |  |  |- gdc-4.8.4+2.062.tar.xz<br> |  |  |- gdc-4.8.4-arm-linux-gnueabi+2.061.2.tar.xz<br> |  |  |- gdc-4.8.4-arm-linux-gnueabi+2.062.tar.xz<br>
 |  |  |- gdc-4.8.4-x86_64-w64-mingw32+2.061.2.tar.xz<br> |  |  |- gdc-4.8.4-x86_64-w64-mingw32+2.062.tar.xz<br> |  |- arm-linux-gnueabi<br> |  |  |- gdc-4.8.4+2.061.2.tar.xz<br> |  |  |- gdc-4.8.4+2.062.tar.xz<br> |  |- x86_64-w64-mingw32<br> |  |  |- gdc-4.8.4+2.061.2.tar.xz<br> |  |  |- gdc-4.8.4+2.062.tar.xz<br>
<div>
 |- 4.9.2<br> |  |- arm-linux-gnueabi<br> |  |- x86_64-linux-gnu<br> |  |- x86_64-w64-mingw32<br></div>
<div>
 |- 5.1.0<br> |  |- arm-linux-gnueabi<br> |  |- x86_64-linux-gnu<br> |  |- x86_64-w64-mingw32<br></div>
<br><br>
</div><div>I want to avoid a situation where there is both gdc-4.8.2-2.061.2-20140430 and gdc-4.8.2-2.061.2-20150430 in the same directory.  We are already overcrowding the name with a version number pair, adding in a timestamp just makes it unreadable.<br><br></div><div>So, rather than having timestamps, I think we should just co-ordinate our binary releases around GCC major and minor updates.  My preference being, if we really must push in an update tarball whose GCC/DMD version pair is already on our FTP server, I'd rather just overwrite the previous version, maybe moving the original into an old-releases directory.<br></div><div><br></div><div>Regards<br></div><div>Iain<br></div><div><br></div></div></div></div>