On Thu, Aug 15, 2013 at 5:11 PM, Gregory Szorc <g...@mozilla.com> wrote:
> On 8/15/13 12:18 PM, Ehsan Akhgari wrote:
>
>> On 2013-08-15 12:42 PM, Gregory Szorc wrote:
>>
>>> On 8/14/13 5:34 PM, Ehsan Akhgari wrote:
>>>
>>>> On Wed, Aug 14, 2013 at 4:44 PM, Joshua Cranmer 🐧
>>>> <pidgeo...@gmail.com>wrote:
>>>>
>>>> On 8/14/2013 3:07 PM, Adam Roach wrote:
>>>>>
>>>>> Over the past few weeks, I've had the build completely break three
>>>>>> time
>>>>>> due to issues with Apple clang 4.1, which tells me that we're not
>>>>>> doing any
>>>>>> regular builds with Apple clang 4.1 (c.f. Bug 892594, Bug 904108,
>>>>>> and the
>>>>>> fact that the current tip of m-i won't link with Apple clang 4.1).
>>>>>>
>>>>>> I'll note that the bugs I mention above are both working around actual
>>>>>> bugs in clang, not missing features.
>>>>>>
>>>>>> Any time I ask in #developers, the answer seems to be that our minimum
>>>>>> version for Apple clang is still 4.1. I would propose that (unless
>>>>>> we're
>>>>>> adapting some of our infra builders to check that we can at least
>>>>>> compile
>>>>>> and link with 4.1), we formally abandon 4.1 as a supported compiler.
>>>>>>
>>>>>>
>>>>> For what it's worth, the usual reference point for clang versions is
>>>>> synchronized with the LLVM versions, so the current tip-of-trunk is
>>>>> 3.3;
>>>>> when dealing with Clang compatibility, all version references refer
>>>>> to that
>>>>> internal number, so Clang 4.1 is a version which doesn't exist yet
>>>>> :-) .
>>>>> Guessing that "Apple clang 4.1" means "the clang shipped with Xcode
>>>>> 4.1",
>>>>> and using Wikipedia to get version info, this means that you're
>>>>> trying to
>>>>> use roughly Clang 3.0 ("based on LLVM 3.0svn"). We've never set a
>>>>> minimum
>>>>> Clang version to my knowledge for C++11 support (given that Clang has
>>>>> been
>>>>> ahead of the curve here), but I consider Clang < 3.1 unbuildable at
>>>>> least
>>>>> on Linux.
>>>>>
>>>>
>>>>
>>>> Should we make this explicit and fail builds with clang < 3.2?
>>>>
>>>
>>> I'd go so far as to suggest that we explicitly require the Mozilla-built
>>> Clang package as defined by the tooltool manifest unless a
>>> --allow-unofficial-toolchain (or similar) configure flag is defined. I'm
>>> not sure if the package used by our builders is easily installed
>>> locally. So I think aggressively pruning the supported toolchain set is
>>> a good way to make development more pain free in the short term.
>>>
>>
>> Currently there is no (easy?) way for us to download those packages. Why
>> would we only allow Mozilla built packages in the first place though?
>> Compiling with newer clang is usually fine, it's old versions of clang
>> which cause these kinds of problems.
>>
>
> I feel that having developers develop on the same toolchain as official
> builds (producing bit-identical builds if possible) would cut down on patch
> development costs due to reducing the frequency of failures resulting from
> discrepancies between the build environments.
>
In addition to what David said, producing bit-identical builds in not
realistic on Windows and Linux where we do PGO. Also, the buildid
generation will probably make this impossible on a different level.
> If nothing else, having the toolchain remain in sync with something in the
> tree gives you the ability to go back and reproduce any old build. If we
> could easily reproduce builds over time, this would make a whole host of
> problems (such as bisecting, long-term analysis, decisions over data
> retention, etc) a lot easier.
>
For clang, we check in the LLVM SVN revision into the tree <
http://mxr.mozilla.org/mozilla-central/source/browser/config/tooltool-manifests/linux64/clang.manifest#3>,
so this is already possible (except for the fact that your build will not
be bit-identical, as mentioned above.)
> Let me rephrase your concern: if we could easily reproduce the official
> build environment on a developer's machine such that the discrepancy for
> build differences is minimized, why shouldn't we do that by default? About
> the only downside I can think of is lesser support for "other" build
> environments. But at the end of the day, Mozilla is only producing builds
> from N configurations, so I think it makes sense for us to keep the number
> of "cared about" configurations as close to N as possible.
>
In addition to what David said, if anything we should make it easier to
build with newer compilers. Also remember that with a
--allow-unofficial-toolchain, you'll make it pretty much impossible for
people to build master/aurora/beta/etc with the same local toolchain,
unless they edit all of their mozconfigs to have that, which defeats the
purpose.
Anyways, to get back to the topic of this thread, I filed bug 905876 to
disallow building with clang < 3.2.
--
Ehsan
<http://ehsanakhgari.org/>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
