On 11/26/14 2:36 PM, Mike Hommey wrote:
> On Wed, Nov 26, 2014 at 08:48:05AM -0800, Gregory Szorc wrote:
>> In the high-level approach, you recognize what the final output is and jump
>> straight to fetching that. e.g. if all you really need is libxul, you'll
>> fetch libxul.so. None of this intermediary .o files foo.
>>
>> Different audiences benefit from the different approaches.
>>
>> Firefox desktop, Fennec, and FxOS developers benefit mostly from a
>> high-level approach, as they don't normally care about changing C++. They
>> can jump straight to the end without paying a penalty of dealing with
>> intermediaries.
>>
>> Gecko/C++ developers care about the low-level approach, as they'll be
>> changing C++ things that invalidate the final output, so they'll be fetching
>> intermediate objects out of necessity.
>>
>> Implementing an effective cache either way relies on several factors:
>>
>> * For a high-level cache, a build system capable of skipping intermediates
>> to fetch the final entity (notably *not* make).
>> * Consistent build environments across release automation and developer
>> machines (otherwise the binaries are different and you sacrifice cache hit
>> rate or "accuracy").
>> * People having fast internet connections to the cache (round trips don't
>> take longer than building locally).
>> * Fixing C++ header dependency hell so when C++ developers change something
>> locally, it doesn't invalidate the world, causing excessive cache misses and
>> local computation.
>> * Writing to a globally distributed cache that is also read by release
>> automation has some fun security challenges.
>> * Having a database to correlate source tree state with build artifacts *or*
>> a build system that is able to compute the equivalent DAG to formulate a
>> cache key (something we can't do today).
> 
> Does the audience that needs high-level cache actually need a cache
> /that/ accurate? I wager using nightly builds would work for the vast
> majority of cases. We "just" need a build mode that doesn't build code,
> which we kinda sorta have, but it's broken at the moment (bug 1063880).

I agree: last Nightly is probably sufficient for most use cases. I would
happily build this mode into the build system if I had time.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to