diff --git a/documentation/getting-started/getting-started-yp-intro.xml b/documentation/getting-started/getting-started-yp-intro.xml index c160c1cf62..45c4b9ffdc 100644 --- a/documentation/getting-started/getting-started-yp-intro.xml +++ b/documentation/getting-started/getting-started-yp-intro.xml @@ -32,12 +32,9 @@ maintained and scaled. - - - - - + + + For further introductory information on the Yocto Project, you @@ -387,6 +384,452 @@
Components and Tools + + The Yocto Project employs a collection of components and + tools used by the project itself, by project developers, + and by those using the Yocto Project. + These components and tools are open source projects and + metadata that are separate from the reference distribution + (Poky) and the OpenEmbedded build system. + Most of the components and tools are downloaded separately. + + + + This section provides brief overviews of the components and + tools associated with the Yocto Project. + + +
+ Development Tools + + + The following list consists of tools that help you develop + images and applications using the Yocto Project: + + + CROPS: + CROPS + is an open source, cross-platform development framework + that leverages + Docker Containers. + CROPS provides an easily managed, extensible environment + that allows you to build binaries for a variety of + architectures on Windows, Linux and Mac OS X hosts. + + + devtool: + This command-line tool is available as part of the + extensible SDK (eSDK) and is its cornerstone. + You can use devtool to help build, + test, and package software within the eSDK. + You can use the tool to optionally integrate what you + build into an image built by the OpenEmbedded build + system. + + The devtool command employs + a number of sub-commands that allow you to add, modify, + and upgrade recipes. + As with the OpenEmbedded build system, “recipes” + represent software packages within + devtool. + When you use devtool add, a recipe + is automatically created. + When you use devtool modify, the + specified existing recipe is used in order to determine + where to get the source code and how to patch it. + In both cases, an environment is set up so that when + you build the recipe a source tree that is under your + control is used in order to allow you to make changes + to the source as desired. + By default, both new recipes and the source go into + a “workspace” directory under the eSDK. + The devtool upgrade command + updates an existing recipe so that you can build it + for an updated set of source files. + + You can read about the + devtool workflow in the Yocto + Project Application Development and Extensible + Software Development Kit (eSDK) Manual in the + "Using devtool in Your SDK Workflow'" + section. + + + Extensible Software Development Kit (eSDK): + The eSDK provides a cross-development toolchain and + libraries tailored to the contents of a specific image. + The eSDK makes it easy to add new applications and + libraries to an image, modify the source for an + existing component, test changes on the target + hardware, and integrate into the rest of the + OpenEmbedded build system. + The eSDK gives you a toolchain experience supplemented + with the powerful set of devtool + commands tailored for the Yocto Project environment. + + + For information on the eSDK, see the + Yocto Project Application Development and Extensible Software Development Kit (eSDK) Manual. + + + Eclipse IDE Plug-in: + This plug-in enables you to use the popular Eclipse + Integrated Development Environment (IDE), which allows + for development using the Yocto Project all within the + Eclipse IDE. + You can work within Eclipse to cross-compile, deploy, + and execute your output into a QEMU emulation session + as well as onto actual target hardware. + + The environment also supports performance + enhancing tools that allow you to perform remote + profiling, tracing, collection of power data, + collection of latency data, and collection of + performance data. + + Once you enable the plug-in, standard Eclipse + functions automatically use the cross-toolchain + and target system libraries. + You can build applications using any of these + libraries. + + For more information on the Eclipse plug-in, + see the + "Working Within Eclipse" + section in the Yocto Project Application Development + and the Extensible Software Development Kit (eSDK) + manual. + + + Toaster: + Toaster is a web interface to the Yocto Project + OpenEmbedded build system. + Toaster allows you to configure, run, and view + information about builds. + + + +
+ +
+ Production Tools + + + The following list consists of tools that help production + related activities using the Yocto Project: + + + Auto Upgrade Helper: + This utility when used in conjunction with the + OpenEmbedded build system (BitBake and OE-Core) + automatically generates upgrades for recipes that + are based on new versions of the recipes published + upstream. + + + Recipe Reporting System: + The Recipe Reporting System tracks recipe versions + available for Yocto Project. + The main purpose of the system is to help you + manage the recipes you maintain and to offer a dynamic + overview of the project. + The Recipe Reporting System tracks is built on top + the of OpenEmbedded Metadata Index, which is a website + that indexes layers for the OpenEmbedded build system. + + + Patchwork: + Patchwork + is a fork of a project originally started by + OzLabs. + The project is a web-based tracking system designed + to streamline the process of bringing contributions + into a project. + The Yocto Project uses Patchwork as an organizational + tool to handle patches, which number in the thousands + for every release. + + + AutoBuilder: + AutoBuilder is a project that automates build tests + and quality assurance (QA). + By using the public AutoBuilder, anyone can determine + the status of the current "master" branch of Poky. + + + A goal of the Yocto Project is to lead the + open source industry with a project that automates + testing and QA procedures. + In doing so, the project encourages a development + community that publishes QA and test plans, publicly + demonstrates QA and test plans, and encourages + development of tools that automate and test and QA + procedures for the benefit of the development + community. + + You can learn more about the AutoBuilder used + by the Yocto Project + here. + + + Cross-Prelink: + Prelinking is the process of pre-computing the load + addresses and link tables generated by the dynamic + linker as compared to doing this at runtime. + Doing this ahead of time results in performance + improvements when the application is launched and + reduced memory usage for libraries shared by many + applications. + + Historically, cross-prelink is a variant of + prelink, which was conceived by + Jakub Jelínek + a number of years ago. + Both prelink and cross-prelink are maintained in the + same repository albeit on separate branches. + By providing an emulated runtime dynamic linker + (i.e. glibc-derived + ld.so emulation), the + cross-prelink project extends the prelink software’s + ability to prelink a sysroot environment. + Additionally, the cross-prelink software enables the + ability to work in sysroot style environments. + + The dynamic linker determines standard load + address calculations based on a variety of factors + such as mapping addresses, library usage, and library + function conflicts. + The prelink tool uses this information, from the + dynamic linker, to determine unique load addresses + for executable and linkable format (ELF) binaries + that are shared libraries and dynamically linked. + The prelink tool modifies these ELF binaries with the + pre-computed information. + The result is faster loading and often lower memory + consumption because more of the library code can + be re-used from shared Copy-On-Write (COW) pages. + + + The original upstream prelink project only + supports running prelink on the end target device + due to the reliance on the target device’s dynamic + linker. + This restriction causes issues when developing a + cross-compiled system. + The cross-prelink adds a synthesized dynamic loader + that runs on the host, thus permitting cross-prelinking + without ever having to run on a read-write target + filesystem. + + + Pseudo: + Pseudo is the Yocto Project implementation of + fakeroot, + which is used to run commands in an environment + that seemingly has root privileges. + + During a build, it can be necessary to perform + operations that require system administrator + privileges. + For example, file ownership or permissions might need + definition. + Pseudo is a tool that you can either use directly or + through the environment variable + LD_PRELOAD. + Either method allows these operations to succeed as + if system administrator privileges exist even + when they do not. + + You can read more about Pseudo in the + "Fakeroot and Pseudo" + section of the Yocto Project Concepts Manual. + + + +
+ +
+ Open-Embedded Build System Components + + + The following list consists of components associated with the + Open-Embedded build system: + + + BitBake: + BitBake is a core component of the Yocto Project and is + used by the OpenEmbedded build system to build images. + While BitBake is key to the build system, BitBake + is maintained separately from the Yocto Project. + + BitBake is a generic task execution engine that + allows shell and Python tasks to be run efficiently + and in parallel while working within complex inter-task + dependency constraints. + In short, BitBake is a build engine that works + through recipes written in a specific format in order + to perform sets of tasks. + + You can learn more about BitBake in the + BitBake User Manual. + + + Openembedded Core: + OpenEmbedded Core (OE-Core) is a common layer of + metadata (i.e. recipes, classes, and associated files) + used by OpenEmbedded-derived systems, which includes + the Yocto Project. + The Yocto Project and the OpenEmbedded Project both + maintain the OpenEmbedded Core. + You can find the OE-Core metadata in the Yocto + Project + Source Repositories + here. + + + Historically, the Yocto Project integrated the + OE-Core metadata throughout the Yocto Project + source repository reference system (Poky). + After Yocto Project Version 1.0, the Yocto Project + and OpenEmbedded agreed to work together and share a + common core set of metadata (OE-Core), which contained + much of the functionality previously found in Poky. + This collaboration achieved a long-standing + OpenEmbedded objective for having a more tightly + controlled and quality-assured core. + The results also fit well with the Yocto Project + objective of achieving a smaller number of fully + featured tools as compared to many different ones. + + + Sharing a core set of metadata results in Poky + as an integration layer on top of OE-Core. + You can see that in this + figure. + The Yocto Project combines various components such as + BitBake, OE-Core, script “glue”, and documentation + for its build system. + + + +
+ +
+ Reference Distribution (Poky) + + + Poky is the Yocto Project reference distribution. + It contains the OpenEmbedded build system (BitBake and OE-Core) + as well as a set of metadata to get you started building your + own distribution. + See the + figure in + "What is the Yocto Project?" section for an illustration + that shows Poky and its relationship with other parts of the + Yocto Project. + + To use the Yocto Project tools and components, you + can download (clone) Poky and use it + to bootstrap your own distribution. + + Poky does not contain binary files. + It is a working example of how to build your own custom + Linux distribution from source. + + +
+ +
+ Packages for Finished Targets + + + The following lists components associated with packages + for finished targets: + + + Matchbox: + Matchbox is an Open Source, base environment for the + X Window System running on non-desktop, embedded + platforms such as handhelds, set-top boxes, kiosks, + and anything else for which screen space, input + mechanisms, or system resources are limited. + + Matchbox consists of a number of interchangeable + and optional applications that you can tailor to a + specific, non-desktop platform to enhance usability + in constrained environments. + + You can find the Matchbox source in its + repository + listed in the Yocto Project + Source Repositories. + + + Opkg + Open PacKaGe management (opkg) is a lightweight + package management system based on the itsy package + (ipkg) management system. + Opkg is written in C and resembles Advanced Package + Tool (APT) and Debian Package (dpkg) in operation. + + + Opkg is intended for use on embedded Linux + devices and is used in this capacity in the + OpenEmbedded + and + OpenWrt + projects, as well as the Yocto Project. + + As best it can, opkg maintains backwards + compatibility with ipkg and conforms to a subset + of Debian’s policy manual regarding control files. + + + + +
+ +
+ Archived Components + + + The Build Appliance is a virtual machine image that enables + you to build and boot a custom embedded Linux image with + the Yocto Project using a non-Linux development system. + + + + Historically, the Build Appliance was the second of three + methods by which you could use the Yocto Project on a system + that was not native to Linux. + + + Hob: + Hob, which is now deprecated and is no longer available + since the 2.1 release of the Yocto Project provided + a rudimentary, GUI-based interface to the Yocto + Project. + Toaster has fully replaced Hob. + + + Build Appliance: + Post Hob, the Build Appliance became available. + It was never recommended that you use the Build + Appliance as a day-to-day production development + environment with the Yocto Project. + Build Appliance was useful as a way to try out + development in the Yocto Project environment. + + + CROPS: + The final and best solution available now for + developing using the Yocto Project on a system + not native to Linux is with + CROPS. + + + +