blob: 03061a79f3af1704ee5274d413a5c3583990108d [file] [log] [blame]
Andrew Geisslerf0343792020-11-18 10:42:21 -06001.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002
3***********************************
4Setting Up to Use the Yocto Project
5***********************************
6
7This chapter provides guidance on how to prepare to use the Yocto
8Project. You can learn about creating a team environment to develop
9using the Yocto Project, how to set up a :ref:`build
Andrew Geissler09209ee2020-12-13 08:44:15 -060010host <dev-manual/start:preparing the build host>`, how to locate
Andrew Geisslerc9f78652020-09-18 14:11:35 -050011Yocto Project source repositories, and how to create local Git
12repositories.
13
Andrew Geisslerc9f78652020-09-18 14:11:35 -050014Creating a Team Development Environment
15=======================================
16
17It might not be immediately clear how you can use the Yocto Project in a
18team development environment, or how to scale it for a large team of
19developers. You can adapt the Yocto Project to many different use cases
20and scenarios; however, this flexibility could cause difficulties if you
21are trying to create a working setup that scales effectively.
22
23To help you understand how to set up this type of environment, this
24section presents a procedure that gives you information that can help
25you get the results you want. The procedure is high-level and presents
26some of the project's most successful experiences, practices, solutions,
27and available technologies that have proved to work well in the past;
28however, keep in mind, the procedure here is simply a starting point.
29You can build off these steps and customize the procedure to fit any
30particular working environment and set of practices.
31
321. *Determine Who is Going to be Developing:* You first need to
33 understand who is going to be doing anything related to the Yocto
34 Project and determine their roles. Making this determination is
35 essential to completing subsequent steps, which are to get your
36 equipment together and set up your development environment's
37 hardware topology.
38
39 The following roles exist:
40
41 - *Application Developer:* This type of developer does application
42 level work on top of an existing software stack.
43
44 - *Core System Developer:* This type of developer works on the
45 contents of the operating system image itself.
46
47 - *Build Engineer:* This type of developer manages Autobuilders and
48 releases. Depending on the specifics of the environment, not all
49 situations might need a Build Engineer.
50
51 - *Test Engineer:* This type of developer creates and manages
52 automated tests that are used to ensure all application and core
53 system development meets desired quality standards.
54
552. *Gather the Hardware:* Based on the size and make-up of the team,
56 get the hardware together. Ideally, any development, build, or test
57 engineer uses a system that runs a supported Linux distribution.
58 These systems, in general, should be high performance (e.g. dual,
59 six-core Xeons with 24 Gbytes of RAM and plenty of disk space). You
60 can help ensure efficiency by having any machines used for testing
61 or that run Autobuilders be as high performance as possible.
62
63 .. note::
64
65 Given sufficient processing power, you might also consider
66 building Yocto Project development containers to be run under
67 Docker, which is described later.
68
693. *Understand the Hardware Topology of the Environment:* Once you
70 understand the hardware involved and the make-up of the team, you
71 can understand the hardware topology of the development environment.
72 You can get a visual idea of the machines and their roles across the
73 development environment.
74
754. *Use Git as Your Source Control Manager (SCM):* Keeping your
76 :term:`Metadata` (i.e. recipes,
77 configuration files, classes, and so forth) and any software you are
78 developing under the control of an SCM system that is compatible
79 with the OpenEmbedded build system is advisable. Of all of the SCMs
80 supported by BitBake, the Yocto Project team strongly recommends using
Andrew Geissler09209ee2020-12-13 08:44:15 -060081 :ref:`overview-manual/development-environment:git`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -050082 Git is a distributed system
83 that is easy to back up, allows you to work remotely, and then
84 connects back to the infrastructure.
85
86 .. note::
87
88 For information about BitBake, see the
Andrew Geissler4c19ea12020-10-27 13:52:24 -050089 :doc:`bitbake:index`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -050090
91 It is relatively easy to set up Git services and create
Andrew Geissler4c19ea12020-10-27 13:52:24 -050092 infrastructure like :yocto_git:`/`, which is based on
Andrew Geisslerc9f78652020-09-18 14:11:35 -050093 server software called ``gitolite`` with ``cgit`` being used to
94 generate the web interface that lets you view the repositories. The
95 ``gitolite`` software identifies users using SSH keys and allows
96 branch-based access controls to repositories that you can control as
97 little or as much as necessary.
98
99 .. note::
100
101 The setup of these services is beyond the scope of this manual.
102 However, sites such as the following exist that describe how to
103 perform setup:
104
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500105 - `Gitolite <https://gitolite.com>`__: Information for
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500106 ``gitolite``.
107
108 - `Interfaces, frontends, and
109 tools <https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools>`__:
110 Documentation on how to create interfaces and frontends for
111 Git.
112
1135. *Set up the Application Development Machines:* As mentioned earlier,
114 application developers are creating applications on top of existing
115 software stacks. Following are some best practices for setting up
116 machines used for application development:
117
118 - Use a pre-built toolchain that contains the software stack
119 itself. Then, develop the application code on top of the stack.
120 This method works well for small numbers of relatively isolated
121 applications.
122
123 - Keep your cross-development toolchains updated. You can do this
124 through provisioning either as new toolchain downloads or as
125 updates through a package update mechanism using ``opkg`` to
126 provide updates to an existing toolchain. The exact mechanics of
127 how and when to do this depend on local policy.
128
129 - Use multiple toolchains installed locally into different
130 locations to allow development across versions.
131
1326. *Set up the Core Development Machines:* As mentioned earlier, core
133 developers work on the contents of the operating system itself.
134 Following are some best practices for setting up machines used for
135 developing images:
136
137 - Have the :term:`OpenEmbedded Build System` available on
138 the developer workstations so developers can run their own builds
139 and directly rebuild the software stack.
140
141 - Keep the core system unchanged as much as possible and do your
142 work in layers on top of the core system. Doing so gives you a
143 greater level of portability when upgrading to new versions of
144 the core system or Board Support Packages (BSPs).
145
146 - Share layers amongst the developers of a particular project and
147 contain the policy configuration that defines the project.
148
1497. *Set up an Autobuilder:* Autobuilders are often the core of the
150 development environment. It is here that changes from individual
151 developers are brought together and centrally tested. Based on this
152 automated build and test environment, subsequent decisions about
153 releases can be made. Autobuilders also allow for "continuous
154 integration" style testing of software components and regression
155 identification and tracking.
156
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500157 See ":yocto_ab:`Yocto Project Autobuilder <>`" for more
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500158 information and links to buildbot. The Yocto Project team has found
159 this implementation works well in this role. A public example of
160 this is the Yocto Project Autobuilders, which the Yocto Project team
161 uses to test the overall health of the project.
162
163 The features of this system are:
164
165 - Highlights when commits break the build.
166
167 - Populates an :ref:`sstate
Andrew Geissler09209ee2020-12-13 08:44:15 -0600168 cache <overview-manual/concepts:shared state cache>` from which
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500169 developers can pull rather than requiring local builds.
170
171 - Allows commit hook triggers, which trigger builds when commits
172 are made.
173
174 - Allows triggering of automated image booting and testing under
175 the QuickEMUlator (QEMU).
176
177 - Supports incremental build testing and from-scratch builds.
178
179 - Shares output that allows developer testing and historical
180 regression investigation.
181
182 - Creates output that can be used for releases.
183
184 - Allows scheduling of builds so that resources can be used
185 efficiently.
186
1878. *Set up Test Machines:* Use a small number of shared, high
188 performance systems for testing purposes. Developers can use these
189 systems for wider, more extensive testing while they continue to
190 develop locally using their primary development system.
191
1929. *Document Policies and Change Flow:* The Yocto Project uses a
193 hierarchical structure and a pull model. Scripts exist to create and
194 send pull requests (i.e. ``create-pull-request`` and
195 ``send-pull-request``). This model is in line with other open source
196 projects where maintainers are responsible for specific areas of the
197 project and a single maintainer handles the final "top-of-tree"
198 merges.
199
200 .. note::
201
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500202 You can also use a more collective push model. The ``gitolite``
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500203 software supports both the push and pull models quite easily.
204
205 As with any development environment, it is important to document the
206 policy used as well as any main project guidelines so they are
207 understood by everyone. It is also a good idea to have
208 well-structured commit messages, which are usually a part of a
209 project's guidelines. Good commit messages are essential when
210 looking back in time and trying to understand why changes were made.
211
212 If you discover that changes are needed to the core layer of the
213 project, it is worth sharing those with the community as soon as
214 possible. Chances are if you have discovered the need for changes,
215 someone else in the community needs them also.
216
21710. *Development Environment Summary:* Aside from the previous steps,
218 some best practices exist within the Yocto Project development
219 environment. Consider the following:
220
Andrew Geissler09209ee2020-12-13 08:44:15 -0600221 - Use :ref:`overview-manual/development-environment:git` as the source control
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500222 system.
223
224 - Maintain your Metadata in layers that make sense for your
Andrew Geissler09209ee2020-12-13 08:44:15 -0600225 situation. See the ":ref:`overview-manual/yp-intro:the yocto project layer model`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500226 section in the Yocto Project Overview and Concepts Manual and the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600227 ":ref:`dev-manual/common-tasks:understanding and creating layers`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500228 section for more information on layers.
229
230 - Separate the project's Metadata and code by using separate Git
Andrew Geissler09209ee2020-12-13 08:44:15 -0600231 repositories. See the ":ref:`overview-manual/development-environment:yocto project source repositories`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500232 section in the Yocto Project Overview and Concepts Manual for
233 information on these repositories. See the "`Locating Yocto
234 Project Source Files <#locating-yocto-project-source-files>`__"
235 section for information on how to set up local Git repositories
236 for related upstream Yocto Project Git repositories.
237
238 - Set up the directory for the shared state cache
239 (:term:`SSTATE_DIR`) where
240 it makes sense. For example, set up the sstate cache on a system
241 used by developers in the same organization and share the same
242 source directories on their machines.
243
244 - Set up an Autobuilder and have it populate the sstate cache and
245 source directories.
246
247 - The Yocto Project community encourages you to send patches to the
248 project to fix bugs or add features. If you do submit patches,
249 follow the project commit guidelines for writing good commit
250 messages. See the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600251 ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500252 section.
253
254 - Send changes to the core sooner than later as others are likely
255 to run into the same issues. For some guidance on mailing lists
256 to use, see the list in the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600257 ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500258 section. For a description
259 of the available mailing lists, see the ":ref:`resources-mailinglist`" section in
260 the Yocto Project Reference Manual.
261
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500262Preparing the Build Host
263========================
264
265This section provides procedures to set up a system to be used as your
266:term:`Build Host` for
267development using the Yocto Project. Your build host can be a native
268Linux machine (recommended), it can be a machine (Linux, Mac, or
269Windows) that uses `CROPS <https://github.com/crops/poky-container>`__,
270which leverages `Docker Containers <https://www.docker.com/>`__ or it
271can be a Windows machine capable of running Windows Subsystem For Linux
272v2 (WSL).
273
274.. note::
275
276 The Yocto Project is not compatible with
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500277 `Windows Subsystem for Linux v1 <https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux>`__.
278 It is compatible but not officially supported nor validated with
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500279 WSLv2. If you still decide to use WSL please upgrade to
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500280 `WSLv2 <https://docs.microsoft.com/en-us/windows/wsl/install-win10>`__.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500281
282Once your build host is set up to use the Yocto Project, further steps
283are necessary depending on what you want to accomplish. See the
284following references for information on how to prepare for Board Support
285Package (BSP) development and kernel development:
286
287- *BSP Development:* See the ":ref:`bsp-guide/bsp:preparing your build host to work with bsp layers`"
288 section in the Yocto Project Board Support Package (BSP) Developer's
289 Guide.
290
Andrew Geissler09209ee2020-12-13 08:44:15 -0600291- *Kernel Development:* See the ":ref:`kernel-dev/common:preparing the build host to work on the kernel`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500292 section in the Yocto Project Linux Kernel Development Manual.
293
294Setting Up a Native Linux Host
295------------------------------
296
297Follow these steps to prepare a native Linux machine as your Yocto
298Project Build Host:
299
3001. *Use a Supported Linux Distribution:* You should have a reasonably
301 current Linux-based host system. You will have the best results with
302 a recent release of Fedora, openSUSE, Debian, Ubuntu, RHEL or CentOS
303 as these releases are frequently tested against the Yocto Project and
304 officially supported. For a list of the distributions under
305 validation and their status, see the ":ref:`Supported Linux
306 Distributions <detailed-supported-distros>`"
307 section in the Yocto Project Reference Manual and the wiki page at
Andrew Geissler09209ee2020-12-13 08:44:15 -0600308 :yocto_wiki:`Distribution Support </Distribution_Support>`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500309
3102. *Have Enough Free Memory:* Your system should have at least 50 Gbytes
311 of free disk space for building images.
312
3133. *Meet Minimal Version Requirements:* The OpenEmbedded build system
314 should be able to run on any modern distribution that has the
315 following versions for Git, tar, Python and gcc.
316
317 - Git 1.8.3.1 or greater
318
319 - tar 1.28 or greater
320
321 - Python 3.5.0 or greater.
322
323 - gcc 5.0 or greater.
324
325 If your build host does not meet any of these three listed version
326 requirements, you can take steps to prepare the system so that you
327 can still use the Yocto Project. See the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600328 ":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500329 section in the Yocto Project Reference Manual for information.
330
3314. *Install Development Host Packages:* Required development host
332 packages vary depending on your build host and what you want to do
333 with the Yocto Project. Collectively, the number of required packages
334 is large if you want to be able to cover all cases.
335
336 For lists of required packages for all scenarios, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600337 ":ref:`ref-manual/system-requirements:required packages for the build host`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500338 section in the Yocto Project Reference Manual.
339
340Once you have completed the previous steps, you are ready to continue
341using a given development path on your native Linux machine. If you are
342going to use BitBake, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600343":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500344section. If you are going
Andrew Geissler09209ee2020-12-13 08:44:15 -0600345to use the Extensible SDK, see the ":doc:`/sdk-manual/extensible`" Chapter in the Yocto
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500346Project Application Development and the Extensible Software Development
Andrew Geissler09209ee2020-12-13 08:44:15 -0600347Kit (eSDK) manual. If you want to work on the kernel, see the :doc:`/kernel-dev/index`. If you are going to use
348Toaster, see the ":doc:`/toaster-manual/setup-and-use`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500349section in the Toaster User Manual.
350
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500351Setting Up to Use CROss PlatformS (CROPS)
352-----------------------------------------
353
354With `CROPS <https://github.com/crops/poky-container>`__, which
355leverages `Docker Containers <https://www.docker.com/>`__, you can
356create a Yocto Project development environment that is operating system
357agnostic. You can set up a container in which you can develop using the
358Yocto Project on a Windows, Mac, or Linux machine.
359
360Follow these general steps to prepare a Windows, Mac, or Linux machine
361as your Yocto Project build host:
362
3631. *Determine What Your Build Host Needs:*
364 `Docker <https://www.docker.com/what-docker>`__ is a software
365 container platform that you need to install on the build host.
366 Depending on your build host, you might have to install different
367 software to support Docker containers. Go to the Docker installation
368 page and read about the platform requirements in "`Supported
Andrew Geisslerc3d88e42020-10-02 09:45:00 -0500369 Platforms <https://docs.docker.com/engine/install/#supported-platforms>`__"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500370 your build host needs to run containers.
371
3722. *Choose What To Install:* Depending on whether or not your build host
373 meets system requirements, you need to install "Docker CE Stable" or
374 the "Docker Toolbox". Most situations call for Docker CE. However, if
375 you have a build host that does not meet requirements (e.g.
376 Pre-Windows 10 or Windows 10 "Home" version), you must install Docker
377 Toolbox instead.
378
3793. *Go to the Install Site for Your Platform:* Click the link for the
380 Docker edition associated with your build host's native software. For
381 example, if your build host is running Microsoft Windows Version 10
382 and you want the Docker CE Stable edition, click that link under
383 "Supported Platforms".
384
3854. *Install the Software:* Once you have understood all the
386 pre-requisites, you can download and install the appropriate
387 software. Follow the instructions for your specific machine and the
388 type of the software you need to install:
389
390 - Install `Docker CE for
Andrew Geisslerc3d88e42020-10-02 09:45:00 -0500391 Windows <https://docs.docker.com/docker-for-windows/install/#install-docker-desktop-on-windows>`__
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500392 for Windows build hosts that meet requirements.
393
394 - Install `Docker CE for
Andrew Geisslerc3d88e42020-10-02 09:45:00 -0500395 MacOs <https://docs.docker.com/docker-for-mac/install/#install-and-run-docker-desktop-on-mac>`__
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500396 for Mac build hosts that meet requirements.
397
398 - Install `Docker Toolbox for
399 Windows <https://docs.docker.com/toolbox/toolbox_install_windows/>`__
400 for Windows build hosts that do not meet Docker requirements.
401
402 - Install `Docker Toolbox for
403 MacOS <https://docs.docker.com/toolbox/toolbox_install_mac/>`__
404 for Mac build hosts that do not meet Docker requirements.
405
406 - Install `Docker CE for
407 CentOS <https://docs.docker.com/install/linux/docker-ce/centos/>`__
408 for Linux build hosts running the CentOS distribution.
409
410 - Install `Docker CE for
411 Debian <https://docs.docker.com/install/linux/docker-ce/debian/>`__
412 for Linux build hosts running the Debian distribution.
413
414 - Install `Docker CE for
415 Fedora <https://docs.docker.com/install/linux/docker-ce/fedora/>`__
416 for Linux build hosts running the Fedora distribution.
417
418 - Install `Docker CE for
419 Ubuntu <https://docs.docker.com/install/linux/docker-ce/ubuntu/>`__
420 for Linux build hosts running the Ubuntu distribution.
421
4225. *Optionally Orient Yourself With Docker:* If you are unfamiliar with
423 Docker and the container concept, you can learn more here -
424 https://docs.docker.com/get-started/.
425
4266. *Launch Docker or Docker Toolbox:* You should be able to launch
427 Docker or the Docker Toolbox and have a terminal shell on your
428 development host.
429
4307. *Set Up the Containers to Use the Yocto Project:* Go to
431 https://github.com/crops/docker-win-mac-docs/wiki and follow
432 the directions for your particular build host (i.e. Linux, Mac, or
433 Windows).
434
435 Once you complete the setup instructions for your machine, you have
436 the Poky, Extensible SDK, and Toaster containers available. You can
437 click those links from the page and learn more about using each of
438 those containers.
439
440Once you have a container set up, everything is in place to develop just
441as if you were running on a native Linux machine. If you are going to
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500442use the Poky container, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600443":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500444section. If you are going to use the Extensible SDK container, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600445":doc:`/sdk-manual/extensible`" Chapter in the Yocto
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500446Project Application Development and the Extensible Software Development
447Kit (eSDK) manual. If you are going to use the Toaster container, see
Andrew Geissler09209ee2020-12-13 08:44:15 -0600448the ":doc:`/toaster-manual/setup-and-use`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500449section in the Toaster User Manual.
450
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500451Setting Up to Use Windows Subsystem For Linux (WSLv2)
452-----------------------------------------------------
453
454With `Windows Subsystem for Linux
455(WSLv2) <https://docs.microsoft.com/en-us/windows/wsl/wsl2-about>`__,
456you can create a Yocto Project development environment that allows you
457to build on Windows. You can set up a Linux distribution inside Windows
458in which you can develop using the Yocto Project.
459
460Follow these general steps to prepare a Windows machine using WSLv2 as
461your Yocto Project build host:
462
4631. *Make sure your Windows 10 machine is capable of running WSLv2:*
464 WSLv2 is only available for Windows 10 builds > 18917. To check which
465 build version you are running, you may open a command prompt on
466 Windows and execute the command "ver".
467 ::
468
469 C:\Users\myuser> ver
470
471 Microsoft Windows [Version 10.0.19041.153]
472
473 If your build is capable of running
474 WSLv2 you may continue, for more information on this subject or
475 instructions on how to upgrade to WSLv2 visit `Windows 10
476 WSLv2 <https://docs.microsoft.com/en-us/windows/wsl/wsl2-install>`__
477
4782. *Install the Linux distribution of your choice inside Windows 10:*
479 Once you know your version of Windows 10 supports WSLv2, you can
480 install the distribution of your choice from the Microsoft Store.
481 Open the Microsoft Store and search for Linux. While there are
482 several Linux distributions available, the assumption is that your
483 pick will be one of the distributions supported by the Yocto Project
484 as stated on the instructions for using a native Linux host. After
485 making your selection, simply click "Get" to download and install the
486 distribution.
487
4883. *Check your Linux distribution is using WSLv2:* Open a Windows
489 PowerShell and run:
490 ::
491
492 C:\WINDOWS\system32> wsl -l -v
493 NAME STATE VERSION
494 *Ubuntu Running 2
495
496 Note the version column which says the WSL version
497 being used by your distribution, on compatible systems, this can be
498 changed back at any point in time.
499
5004. *Optionally Orient Yourself on WSL:* If you are unfamiliar with WSL,
501 you can learn more here -
502 https://docs.microsoft.com/en-us/windows/wsl/wsl2-about.
503
5045. *Launch your WSL Distibution:* From the Windows start menu simply
505 launch your WSL distribution just like any other application.
506
5076. *Optimize your WSLv2 storage often:* Due to the way storage is
508 handled on WSLv2, the storage space used by the undelying Linux
509 distribution is not reflected immedately, and since bitbake heavily
510 uses storage, after several builds, you may be unaware you are
511 running out of space. WSLv2 uses a VHDX file for storage, this issue
512 can be easily avoided by manually optimizing this file often, this
513 can be done in the following way:
514
515 1. *Find the location of your VHDX file:* First you need to find the
516 distro app package directory, to achieve this open a Windows
517 Powershell as Administrator and run:
518 ::
519
520 C:\WINDOWS\system32> Get-AppxPackage -Name "*Ubuntu*" | Select PackageFamilyName
521 PackageFamilyName
522 -----------------
523 CanonicalGroupLimited.UbuntuonWindows_79abcdefgh
524
525
526 You should now
527 replace the PackageFamilyName and your user on the following path
528 to find your VHDX file:
529 ::
530
531 ls C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\
532 Mode LastWriteTime Length Name
533 -a---- 3/14/2020 9:52 PM 57418973184 ext4.vhdx
534
535 Your VHDX file path is:
536 ``C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx``
537
538 2. *Optimize your VHDX file:* Open a Windows Powershell as
539 Administrator to optimize your VHDX file, shutting down WSL first:
540 ::
541
542 C:\WINDOWS\system32> wsl --shutdown
543 C:\WINDOWS\system32> optimize-vhd -Path C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx -Mode full
544
545 A progress bar should be shown while optimizing the
546 VHDX file, and storage should now be reflected correctly on the
547 Windows Explorer.
548
549.. note::
550
551 The current implementation of WSLv2 does not have out-of-the-box
552 access to external devices such as those connected through a USB
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500553 port, but it automatically mounts your ``C:`` drive on ``/mnt/c/``
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500554 (and others), which you can use to share deploy artifacts to be later
555 flashed on hardware through Windows, but your build directory should
556 not reside inside this mountpoint.
557
558Once you have WSLv2 set up, everything is in place to develop just as if
559you were running on a native Linux machine. If you are going to use the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600560Extensible SDK container, see the ":doc:`/sdk-manual/extensible`" Chapter in the Yocto
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500561Project Application Development and the Extensible Software Development
562Kit (eSDK) manual. If you are going to use the Toaster container, see
Andrew Geissler09209ee2020-12-13 08:44:15 -0600563the ":doc:`/toaster-manual/setup-and-use`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500564section in the Toaster User Manual.
565
566Locating Yocto Project Source Files
567===================================
568
569This section shows you how to locate, fetch and configure the source
570files you'll need to work with the Yocto Project.
571
572.. note::
573
574 - For concepts and introductory information about Git as it is used
Andrew Geissler09209ee2020-12-13 08:44:15 -0600575 in the Yocto Project, see the ":ref:`overview-manual/development-environment:git`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500576 section in the Yocto Project Overview and Concepts Manual.
577
578 - For concepts on Yocto Project source repositories, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600579 ":ref:`overview-manual/development-environment:yocto project source repositories`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500580 section in the Yocto Project Overview and Concepts Manual."
581
582Accessing Source Repositories
583-----------------------------
584
Andrew Geissler09209ee2020-12-13 08:44:15 -0600585Working from a copy of the upstream :ref:`dev-manual/start:accessing source repositories` is the
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500586preferred method for obtaining and using a Yocto Project release. You
587can view the Yocto Project Source Repositories at
588:yocto_git:`/`. In particular, you can find the ``poky``
Andrew Geissler09209ee2020-12-13 08:44:15 -0600589repository at :yocto_git:`/poky`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500590
591Use the following procedure to locate the latest upstream copy of the
592``poky`` Git repository:
593
5941. *Access Repositories:* Open a browser and go to
595 :yocto_git:`/` to access the GUI-based interface into the
596 Yocto Project source repositories.
597
5982. *Select the Repository:* Click on the repository in which you are
599 interested (e.g. ``poky``).
600
6013. *Find the URL Used to Clone the Repository:* At the bottom of the
602 page, note the URL used to clone that repository
Andrew Geissler09209ee2020-12-13 08:44:15 -0600603 (e.g. :yocto_git:`/poky`).
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500604
605 .. note::
606
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500607 For information on cloning a repository, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600608 ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" section.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500609
610Accessing Index of Releases
611---------------------------
612
613Yocto Project maintains an Index of Releases area that contains related
614files that contribute to the Yocto Project. Rather than Git
615repositories, these files are tarballs that represent snapshots in time
616of a given component.
617
618.. note::
619
620 The recommended method for accessing Yocto Project components is to
621 use Git to clone the upstream repository and work from within that
622 locally cloned repository. The procedure in this section exists
623 should you desire a tarball snapshot of any given component.
624
625Follow these steps to locate and download a particular tarball:
626
6271. *Access the Index of Releases:* Open a browser and go to
Andrew Geisslerc3d88e42020-10-02 09:45:00 -0500628 :yocto_dl:`Index of Releases </releases>`. The
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500629 list represents released components (e.g. ``bitbake``, ``sato``, and
630 so on).
631
632 .. note::
633
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500634 The ``yocto`` directory contains the full array of released Poky
635 tarballs. The ``poky`` directory in the Index of Releases was
636 historically used for very early releases and exists now only for
637 retroactive completeness.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500638
6392. *Select a Component:* Click on any released component in which you
640 are interested (e.g. ``yocto``).
641
6423. *Find the Tarball:* Drill down to find the associated tarball. For
643 example, click on ``yocto-&DISTRO;`` to view files associated with the
644 Yocto Project &DISTRO; release (e.g.
645 ``&YOCTO_POKY;.tar.bz2``, which is the
646 released Poky tarball).
647
6484. *Download the Tarball:* Click the tarball to download and save a
649 snapshot of the given component.
650
651Using the Downloads Page
652------------------------
653
654The :yocto_home:`Yocto Project Website <>` uses a "DOWNLOADS" page
655from which you can locate and download tarballs of any Yocto Project
656release. Rather than Git repositories, these files represent snapshot
657tarballs similar to the tarballs located in the Index of Releases
658described in the "`Accessing Index of
659Releases <#accessing-index-of-releases>`__" section.
660
661.. note::
662
663 The recommended method for accessing Yocto Project components is to
664 use Git to clone a repository and work from within that local
665 repository. The procedure in this section exists should you desire a
666 tarball snapshot of any given component.
667
6681. *Go to the Yocto Project Website:* Open The
669 :yocto_home:`Yocto Project Website <>` in your browser.
670
6712. *Get to the Downloads Area:* Select the "DOWNLOADS" item from the
672 pull-down "SOFTWARE" tab menu near the top of the page.
673
6743. *Select a Yocto Project Release:* Use the menu next to "RELEASE" to
675 display and choose a recent or past supported Yocto Project release
676 (e.g. &DISTRO_NAME_NO_CAP;, &DISTRO_NAME_NO_CAP_MINUS_ONE;, and so forth).
677
678 .. note::
679
680 For a "map" of Yocto Project releases to version numbers, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600681 :yocto_wiki:`Releases </Releases>` wiki page.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500682
683 You can use the "RELEASE ARCHIVE" link to reveal a menu of all Yocto
684 Project releases.
685
6864. *Download Tools or Board Support Packages (BSPs):* From the
687 "DOWNLOADS" page, you can download tools or BSPs as well. Just scroll
688 down the page and look for what you need.
689
690Accessing Nightly Builds
691------------------------
692
693Yocto Project maintains an area for nightly builds that contains tarball
694releases at https://autobuilder.yocto.io//pub/nightly/. These builds include Yocto
695Project releases ("poky"), toolchains, and builds for supported
696machines.
697
698Should you ever want to access a nightly build of a particular Yocto
699Project component, use the following procedure:
700
7011. *Locate the Index of Nightly Builds:* Open a browser and go to
702 https://autobuilder.yocto.io//pub/nightly/ to access the Nightly Builds.
703
7042. *Select a Date:* Click on the date in which you are interested. If
705 you want the latest builds, use "CURRENT".
706
7073. *Select a Build:* Choose the area in which you are interested. For
708 example, if you are looking for the most recent toolchains, select
709 the "toolchain" link.
710
7114. *Find the Tarball:* Drill down to find the associated tarball.
712
7135. *Download the Tarball:* Click the tarball to download and save a
714 snapshot of the given component.
715
716Cloning and Checking Out Branches
717=================================
718
719To use the Yocto Project for development, you need a release locally
720installed on your development system. This locally installed set of
721files is referred to as the :term:`Source Directory`
722in the Yocto Project documentation.
723
724The preferred method of creating your Source Directory is by using
Andrew Geissler09209ee2020-12-13 08:44:15 -0600725:ref:`overview-manual/development-environment:git` to clone a local copy of the upstream
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500726``poky`` repository. Working from a cloned copy of the upstream
727repository allows you to contribute back into the Yocto Project or to
728simply work with the latest software on a development branch. Because
729Git maintains and creates an upstream repository with a complete history
730of changes and you are working with a local clone of that repository,
731you have access to all the Yocto Project development branches and tag
732names used in the upstream repository.
733
734Cloning the ``poky`` Repository
735-------------------------------
736
737Follow these steps to create a local version of the upstream
738:term:`Poky` Git repository.
739
7401. *Set Your Directory:* Change your working directory to where you want
741 to create your local copy of ``poky``.
742
7432. *Clone the Repository:* The following example command clones the
744 ``poky`` repository and uses the default name "poky" for your local
745 repository:
746 ::
747
748 $ git clone git://git.yoctoproject.org/poky
749 Cloning into 'poky'...
750 remote: Counting objects: 432160, done.
751 remote: Compressing objects: 100% (102056/102056), done.
752 remote: Total 432160 (delta 323116), reused 432037 (delta 323000)
753 Receiving objects: 100% (432160/432160), 153.81 MiB | 8.54 MiB/s, done.
754 Resolving deltas: 100% (323116/323116), done.
755 Checking connectivity... done.
756
757 Unless you
758 specify a specific development branch or tag name, Git clones the
759 "master" branch, which results in a snapshot of the latest
760 development changes for "master". For information on how to check out
761 a specific development branch or on how to check out a local branch
762 based on a tag name, see the "`Checking Out By Branch in
763 Poky <#checking-out-by-branch-in-poky>`__" and `Checking Out By Tag
764 in Poky <#checkout-out-by-tag-in-poky>`__" sections, respectively.
765
766 Once the local repository is created, you can change to that
767 directory and check its status. Here, the single "master" branch
768 exists on your system and by default, it is checked out:
769 ::
770
771 $ cd ~/poky
772 $ git status
773 On branch master
774 Your branch is up-to-date with 'origin/master'.
775 nothing to commit, working directory clean
776 $ git branch
777 * master
778
779 Your local repository of poky is identical to the
780 upstream poky repository at the time from which it was cloned. As you
781 work with the local branch, you can periodically use the
782 ``git pull --rebase`` command to be sure you are up-to-date
783 with the upstream branch.
784
785Checking Out by Branch in Poky
786------------------------------
787
788When you clone the upstream poky repository, you have access to all its
789development branches. Each development branch in a repository is unique
790as it forks off the "master" branch. To see and use the files of a
791particular development branch locally, you need to know the branch name
792and then specifically check out that development branch.
793
794.. note::
795
796 Checking out an active development branch by branch name gives you a
797 snapshot of that particular branch at the time you check it out.
798 Further development on top of the branch that occurs after check it
799 out can occur.
800
8011. *Switch to the Poky Directory:* If you have a local poky Git
802 repository, switch to that directory. If you do not have the local
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500803 copy of poky, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600804 ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500805 section.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500806
8072. *Determine Existing Branch Names:*
808 ::
809
810 $ git branch -a
811 * master
812 remotes/origin/1.1_M1
813 remotes/origin/1.1_M2
814 remotes/origin/1.1_M3
815 remotes/origin/1.1_M4
816 remotes/origin/1.2_M1
817 remotes/origin/1.2_M2
818 remotes/origin/1.2_M3
819 . . .
820 remotes/origin/thud
821 remotes/origin/thud-next
822 remotes/origin/warrior
823 remotes/origin/warrior-next
824 remotes/origin/zeus
825 remotes/origin/zeus-next
826 ... and so on ...
827
8283. *Check out the Branch:* Check out the development branch in which you
829 want to work. For example, to access the files for the Yocto Project
830 &DISTRO; Release (&DISTRO_NAME;), use the following command:
831 ::
832
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500833 $ git checkout -b &DISTRO_NAME_NO_CAP; origin/&DISTRO_NAME_NO_CAP;
834 Branch &DISTRO_NAME_NO_CAP; set up to track remote branch &DISTRO_NAME_NO_CAP; from origin.
835 Switched to a new branch '&DISTRO_NAME_NO_CAP;'
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500836
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500837 The previous command checks out the "&DISTRO_NAME_NO_CAP;" development
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500838 branch and reports that the branch is tracking the upstream
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500839 "origin/&DISTRO_NAME_NO_CAP;" branch.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500840
841 The following command displays the branches that are now part of your
842 local poky repository. The asterisk character indicates the branch
843 that is currently checked out for work:
844 ::
845
846 $ git branch
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500847 master
848 * &DISTRO_NAME_NO_CAP;
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500849
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500850Checking Out by Tag in Poky
851---------------------------
852
853Similar to branches, the upstream repository uses tags to mark specific
854commits associated with significant points in a development branch (i.e.
855a release point or stage of a release). You might want to set up a local
856branch based on one of those points in the repository. The process is
857similar to checking out by branch name except you use tag names.
858
859.. note::
860
861 Checking out a branch based on a tag gives you a stable set of files
862 not affected by development on the branch above the tag.
863
8641. *Switch to the Poky Directory:* If you have a local poky Git
865 repository, switch to that directory. If you do not have the local
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500866 copy of poky, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600867 ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500868 section.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500869
8702. *Fetch the Tag Names:* To checkout the branch based on a tag name,
871 you need to fetch the upstream tags into your local repository:
872 ::
873
874 $ git fetch --tags
875 $
876
8773. *List the Tag Names:* You can list the tag names now:
878 ::
879
880 $ git tag
881 1.1_M1.final
882 1.1_M1.rc1
883 1.1_M1.rc2
884 1.1_M2.final
885 1.1_M2.rc1
886 .
887 .
888 .
889 yocto-2.5
890 yocto-2.5.1
891 yocto-2.5.2
892 yocto-2.5.3
893 yocto-2.6
894 yocto-2.6.1
895 yocto-2.6.2
896 yocto-2.7
897 yocto_1.5_M5.rc8
898
899
9004. *Check out the Branch:*
901 ::
902
903 $ git checkout tags/yocto-&DISTRO; -b my_yocto_&DISTRO;
904 Switched to a new branch 'my_yocto_&DISTRO;'
905 $ git branch
906 master
907 * my_yocto_&DISTRO;
908
909 The previous command creates and
910 checks out a local branch named "my_yocto_&DISTRO;", which is based on
911 the commit in the upstream poky repository that has the same tag. In
912 this example, the files you have available locally as a result of the
913 ``checkout`` command are a snapshot of the "&DISTRO_NAME_NO_CAP;"
914 development branch at the point where Yocto Project &DISTRO; was
915 released.