Re: Removing tinderbox-builds from archive.mozilla.org
On Tue, 29 May 2018 at 14:21, L. David Baron wrote:
>
> On Monday 2018-05-28 15:52 -0400, Chris AtLee wrote:
> > Here's a bit of a strawman proposal...What if we keep the
> > {mozilla-central,mozilla-inbound,autoland}-{linux,linux64,macosx64,win32,win64}{,-pgo}/
> > directories in tinderbox-builds for now, and delete all the others. Does
> > that cover the majority of the use cases for wanting to access these old
> > builds?
> >
> > I'm guessing the historical builds for old esr branches aren't useful now.
> > Nor are the mozilla-aurora, mozilla-beta, mozilla-release, or b2g-inbound
> > builds.
>
> This seems reasonable to me, with the one caveat that I think
> b2g-inbound belongs in the other bucket. It was essentially used as
> another peer to mozilla-inbound and autoland, and while many of the
> changes landed there were b2g-only, many of them weren't, and may
> have caused regressions that affect products that we still maintain.
Ok, we can do that.
For mobile, I haven't heard anybody express a desire to keep around
old CI builds in
https://archive.mozilla.org/pub/mobile/tinderbox-builds/, so I'm
planning to have those deleted in July.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Update on rustc/clang goodness
On Wed, May 30, 2018 at 5:02 PM, Anthony Jones wrote: > On Thursday, 31 May 2018 02:44:51 UTC+12, Tom Ritter wrote: > > Oh. Are we doing this rustc inlining development on a particular old > > version of clang? I'm not even close to getting CFI ready but I'm > > basically working off llvm trunk as I'm finding and filing llvm bugs > > and working with llvm devs to get them fixed > > We don't have experience with cross language LTO. It is difficult to > predict but relatively easy to try. Here's what we do know: > > In order for the linker to do LTO, it needs to be able to understand the > llvm-ir from both clang and rustc. For the most part this means having an > lld verison more recent than the compilers. In theory the newer linker can > read old versions of llvm-ir. Unfortunately llvm-ir changes over time and > while some effort goes into making it backward compatible, it seems > reasonable to expect a large gap between clang and rustc versions may fall > short of excellence. > > We may be able to get away with heterogenous clang/rustc/lld versions, but > it may be more trouble than it is worth. Alternatively we may need to keep > rustc/clang/lld in lock step with all that it entails. It is possible that > in the end we decide the whole thing isn't worth the trouble. Time will > tell. > LLVM has this policy on IR backwards compatibility: https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility In short, newer compiler versions can be expected to read and compile older IRs going back to LLVM 3.0 correctly, while fewer guarantees exist to keep debug info working. All backwards incompatible changes are required to be recorded in https://github.com/llvm-mirror/llvm/blob/master/test/Bitcode/compatibility.ll (and its versioned counterparts in the same directory) per each release. Per this policy, as long as our LLVM toolchain comes from the same major release we should be mostly fine, except for occasional bugs. Cheers, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: clang prefered for local builds on *nix
Hi, As of bug 1253064 landed earlier today (and now merged on central), local builds on *nix (Linux, BSDs, etc.) will prefer to use clang over gcc by default. If you still prefer to build with gcc instead of clang, you can do so by setting CC=gcc in your environment or adding ac_add_options CC=gcc in your mozconfig. This doesn't affect builds using --enable-release or MOZILLA_OFFICIAL, which means it doesn't affect the builds we or downstreams ship (as long as they are using those options, which they should be). Cheers, Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
