On 10 July 2015 at 14:45, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:
> I thinks it's time to push some new binary releases to gdcproject.org > (gcc-5, intrinsics for checkedint, ...). We should first get some structure > into our download archive though: ftp://ftp.gdcproject.org/binaries/ > > 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. > > > 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. http://ftp.digitalmars.com/LATEST_GDC By all means, we can raise a PR with Travis to move it elsewhere, then remove the rest of the old structure later. > Another question is how exactly the new directory layout should look like. > I think we definitely need host folders as a top-level structure: > > /binaries > |- x86_64-linux-gnu > |- x86_64-w64-mingw32 > |- arm-linux-gnueabi > > Do we want to have the target as a directory? GCC version? Frontend > version? > 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: > > /binaries > |- x86_64-linux-gnu > | |- 2.061 > | | |- x86_64-w64-mingw32 > | | | |- x86_64-w64-mingw32_2.061.2_gcc4.8.2_AAAA_20140430.tar.xz > | | | |- x86_64-w64-mingw32_2.061.2_gcc4.8.2_BBBB_20140430.tar.xz > | | |- arm-linux-gnueabi > | |- 2.062 > |- x86_64-w64-mingw32 > |- arm-linux-gnueabi > > Another question: DMD frontend sub-releases in one folder? > (2.061|2.061.1|2.061.2) > > 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. eg: /binaries |- 4.8.4 | |- x86_64-linux-gnu | | |- gdc-4.8.4+2.061.2.tar.xz | | |- gdc-4.8.4+2.062.tar.xz | | |- gdc-4.8.4-arm-linux-gnueabi+2.061.2.tar.xz | | |- gdc-4.8.4-arm-linux-gnueabi+2.062.tar.xz | | |- gdc-4.8.4-x86_64-w64-mingw32+2.061.2.tar.xz | | |- gdc-4.8.4-x86_64-w64-mingw32+2.062.tar.xz | |- arm-linux-gnueabi | | |- gdc-4.8.4+2.061.2.tar.xz | | |- gdc-4.8.4+2.062.tar.xz | |- x86_64-w64-mingw32 | | |- gdc-4.8.4+2.061.2.tar.xz | | |- gdc-4.8.4+2.062.tar.xz |- 4.9.2 | |- arm-linux-gnueabi | |- x86_64-linux-gnu | |- x86_64-w64-mingw32 |- 5.1.0 | |- arm-linux-gnueabi | |- x86_64-linux-gnu | |- x86_64-w64-mingw32 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. 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. Regards Iain
