I think you missed that I was responding to an email regarding the CI build. i.e. how Jenkins builds the code. This is not how a developer builds the code on their own system. I realize reading my own comments I never mentioned that I was referring to the CI build.
See inline [geo] From: Gregg Reynolds [mailto:[email protected]] Sent: Thursday, November 1, 2018 1:32 PM To: Nash, George <[email protected]> Cc: Mats Wichmann <[email protected]>; iotivity-dev <[email protected]> Subject: Re: [dev] caching build objects in scons On Tue, Oct 30, 2018, 5:21 PM George Nash <[email protected]<mailto:[email protected]>> 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. How do you think build tools decide what to compile and what not to compile? [geo] Have you ever worked on a project that the CI build cached build products? I personally have not. Number one reason for not using a cached build. "Reliability". - Case 1: A problem is solved just by doing a clean build. A non-starter, unless you're building Hello World. I do not need a clean 3 hour build if I changed 1 line of code. [geo] When developing I absolutely want cached builds. This discussion is about the CI build on Jenkins not on a developers machine. Since each build on the CI build system starts with a clean slate it is the same as doing a fresh download and build. This is part of the reason each commit takes so long to become verified. What Mats was suggesting was somehow using the cached build products from another build to try and speed up the CI build. - Case 2: A problem is hidden because a left over build product from the cached build items. Only a problem if your build tool fails to catch the problem. [geo] With SCons this type of build problem, is typically a result of using a Glob which just grabs all the files of a given type in a folder. It will grab files left over from other builds. If you don’t use the Glob command in SCons it is unlikely to be a problem. A false failure like Case 1 where the build fails but can be fixed with a clean build is annoying but not a critical problem It is a critical problem, economically. That's the whole point of build tools that optimize building. [geo] yep I agree but this was a response to the CI build. Not a local build. as long as there is a way to force a clean build. The big problem is Case 2 where it passes because of picking up something from the cached build. That just means your build tooling is flawed. [geo] not always the logic in the build script can be flawed causing the same problem. If all build tools were flawless you would never need to do a clean build. The error will, likely, not be caught till it is merged. Both problems I agree are unusual but they still happen. I am all for speeding up the build but I suspect adding cached build would cause more problems than its worth. All "modern" build tools use caching, one way or another. Without it they would have no way of knowing what to build and what not to build. G -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9991): https://lists.iotivity.org/g/iotivity-dev/message/9991 Mute This Topic: https://lists.iotivity.org/mt/27787640/21656 Group Owner: [email protected] Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
