From a41a805500cab281fba15bd8e5d3e60b88d0d4be Mon Sep 17 00:00:00 2001 From: Timo Mueller Date: Fri, 8 Feb 2013 09:16:33 -0600 Subject: documentation: Part 1 of 2 updates to integrating docs to Eclipse help. Hi, the generation of eclipse help files has been merged from the timo branch to the master. Since the creation of the timo branch there have been some changes to the master branch (e.g. new documentation, renamed documentation). This patch set does some cleanup for the renamed documentation and adds eclipse help generation support to the new documentation. 01: Removes the 'the' from the document titles 02..04: Cleanup obsolete artifacts resulting from the merge 05..08: Add eclipse help generation for ref-manual 09..13: Add eclipse help generation for kernel-dev 14..18: Add eclipse help generation for profile-manual Best regards, Timo This patch set originally contained 18 patches. I (Scott Rifenbark) had to push these changes as two parts. This is the first part. It does not include creation of the three cusomization files. (From yocto-docs rev: 9b1889f6e31ee70dae704fa08763fb9196616dad) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- .../html/poky-ref-manual/overall-architecture.html | 31 ---------------------- 1 file changed, 31 deletions(-) delete mode 100644 documentation/ref-manual/eclipse/html/poky-ref-manual/overall-architecture.html (limited to 'documentation/ref-manual/eclipse/html/poky-ref-manual/overall-architecture.html') diff --git a/documentation/ref-manual/eclipse/html/poky-ref-manual/overall-architecture.html b/documentation/ref-manual/eclipse/html/poky-ref-manual/overall-architecture.html deleted file mode 100644 index 89a6979603..0000000000 --- a/documentation/ref-manual/eclipse/html/poky-ref-manual/overall-architecture.html +++ /dev/null @@ -1,31 +0,0 @@ - - - -3.2.1. Overall Architecture - - - - - - - -
-

-3.2.1. Overall Architecture

-

- When determining what parts of the system need to be built, BitBake - uses a per-task basis and does not use a per-recipe basis. - You might wonder why using a per-task basis is preferred over a per-recipe basis. - To help explain, consider having the IPK packaging backend enabled and then switching to DEB. - In this case, do_install and do_package - output are still valid. - However, with a per-recipe approach, the build would not include the - .deb files. - Consequently, you would have to invalidate the whole build and rerun it. - Rerunning everything is not the best situation. - Also in this case, the core must be "taught" much about specific tasks. - This methodology does not scale well and does not allow users to easily add new tasks - in layers or as external recipes without touching the packaged-staging core. -

-
- -- cgit v1.2.3-54-g00ecf