On 10/30/18 4:21 PM, Nash, George wrote: > Using a cached build sounds like a good idea on paper. > > I honestly have only worked on projects that do not use a cached build. For a > very long time I wanted to move to a build that used a cached build to speed > up the build. After a few years, I have come to the conclusion a cached build > is not a good idea. > > Number one reason for not using a cached build. "Reliability". > - Case 1: A problem is solved just by doing a clean build. > - Case 2: A problem is hidden because a left over build product from the > cached build items.
if there are reliability problems, the feature is pretty much useless and it would be fair to consider that a nonstarter. I can't comment on that for scons, as I don't have enough experience with it, however the way the hashes are computed ought to make it pretty hard for there to be a negative clash - a leftover build product being used that is not correct for the current build. And the other way around - not reusing an artifact that could have been - just costs you the time you would otherwise have saved. As to other thoughts on caching: Gregg's favorite build tool, bazel, just caches without you asking (which you can override), it's considered important enough by Google to make that the default. But that's bazel; it appears scons' caching is not nearly as widely used. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9972): https://lists.iotivity.org/g/iotivity-dev/message/9972 Mute This Topic: https://lists.iotivity.org/mt/27787640/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
