2808 2012-07-20 15:40:44 +0000 Add an illustration showing "source" and "destination" directories 2013-09-30 08:09:10 +0000 1 1 9 Documentation Quick Start quick-start unspecified x86 Multiple VERIFIED FIXED 27 September 2013: RESOLVED Medium normal 1.5 1 david.c.stewart srifenbark bluelightning corneliux.stoicescu david.c.stewart jessica.zhang poky.doc.watcher poky.watcher richard.purdie sgw srifenbark --- --- Done (doc changes complete) oldest_to_newest 23335 0 david.c.stewart 2012-07-20 15:40:44 +0000 This was an idea from Gunnar Anderson of Volvo. Suggested that it would really help to understand which directories are the sources of things and which are the destinations. This would facilitate knowing new people knowing which directories are safe to delete if you want to have the system rebuild things. Destination directories should include downloads directory, shared state, tmp... This picture might go in quickstart or might be in the development or reference guides. 24501 1 srifenbark 2012-08-27 15:39:37 +0000 Adding Richard Purdie and Paul Eggleton to the CC list. Can someone provide me with the basic "from" and "to" directories used during a typical image build? I would like to create this illustration that shows the user where things come from and where they go to during a build. Scott 24577 2 bluelightning 2012-08-29 08:32:21 +0000 The inputs you can't really delete would only be the metadata (layers containing recipes, classes, configuration etc.), and conf/* under the build directory; and, if you have any recipes pointing to local source files or repositories then those would be in the inputs as well - you wouldn't have any of those out of the box, but if you were developing your own software to be built by the build system as most people building a product would be, then you would have. Everything else (TMPDIR, SSTATEDIR, DL_DIR, ...) is output. One thought that comes to mind however is that we should also answer the related question "what should I keep if I want to be able to reproduce the build at a later date?" In answering that I would suggest keeping the contents of the aforementioned inputs as well as at least SSTATEDIR and DL_DIR, although there are circumstances under which those won't completely result in the same output - e.g. we now have a default setting which keeps the sstate files for native recipes separated by the host distribution; thus if you moved these to a new machine with a different distro they at least will be rebuilt by default. We need to specifically resolve and document this topic IMO. 30175 3 corneliux.stoicescu 2013-02-27 15:24:40 +0000 Scott, do you need any more information on this subject? 30181 4 srifenbark 2013-02-27 17:12:46 +0000 I will take the information from Paul's comment and create a rough drawing and then include it in a further comment for this bug. We can assess it and build on it from there. Scott 36903 5 srifenbark 2013-09-18 18:21:07 +0000 Hi, I am marking this extensive section for review now. I have been working on it for a long time closely with Paul Eggleton. It is complete now and there probably is time for changes if they are communicated to me fairly quickly. The figures and some of the flow have been previously reviewed by Dave Stewart and I took action on that review. The idea of the section is a mid-level, detailed look at the overall BitBake process when generating an image or SDK. The section does not delve overly deep into the bowels of the system but tries for a depth that would help the user grasp the overall process better with regard to output directories, variables, and input sources. Here is the link: http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#closer-look Thanks, Scott 37305 6 srifenbark 2013-09-27 21:15:15 +0000 Completed this new chapter for the Yocto Project Reference Manual. You can view it at http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#closer-look. Marking as RESOLVED. Scottsection 37326 7 corneliux.stoicescu 2013-09-30 08:09:10 +0000 The new section looks good. Great addition to the manual. Setting to VERIFIED.