diff options
Diffstat (limited to 'documentation/overview-manual/development-environment.rst')
-rw-r--r-- | documentation/overview-manual/development-environment.rst | 665 |
1 files changed, 665 insertions, 0 deletions
diff --git a/documentation/overview-manual/development-environment.rst b/documentation/overview-manual/development-environment.rst new file mode 100644 index 0000000000..9a2997d9fc --- /dev/null +++ b/documentation/overview-manual/development-environment.rst | |||
@@ -0,0 +1,665 @@ | |||
1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | ||
2 | |||
3 | ***************************************** | ||
4 | The Yocto Project Development Environment | ||
5 | ***************************************** | ||
6 | |||
7 | This chapter takes a look at the Yocto Project development environment. | ||
8 | The chapter provides Yocto Project Development environment concepts that | ||
9 | help you understand how work is accomplished in an open source | ||
10 | environment, which is very different as compared to work accomplished in | ||
11 | a closed, proprietary environment. | ||
12 | |||
13 | Specifically, this chapter addresses open source philosophy, source | ||
14 | repositories, workflows, Git, and licensing. | ||
15 | |||
16 | Open Source Philosophy | ||
17 | ====================== | ||
18 | |||
19 | Open source philosophy is characterized by software development directed | ||
20 | by peer production and collaboration through an active community of | ||
21 | developers. Contrast this to the more standard centralized development | ||
22 | models used by commercial software companies where a finite set of | ||
23 | developers produces a product for sale using a defined set of procedures | ||
24 | that ultimately result in an end product whose architecture and source | ||
25 | material are closed to the public. | ||
26 | |||
27 | Open source projects conceptually have differing concurrent agendas, | ||
28 | approaches, and production. These facets of the development process can | ||
29 | come from anyone in the public (community) who has a stake in the | ||
30 | software project. The open source environment contains new copyright, | ||
31 | licensing, domain, and consumer issues that differ from the more | ||
32 | traditional development environment. In an open source environment, the | ||
33 | end product, source material, and documentation are all available to the | ||
34 | public at no cost. | ||
35 | |||
36 | A benchmark example of an open source project is the Linux kernel, which | ||
37 | was initially conceived and created by Finnish computer science student | ||
38 | Linus Torvalds in 1991. Conversely, a good example of a non-open source | ||
39 | project is the Windows family of operating systems developed by | ||
40 | Microsoft Corporation. | ||
41 | |||
42 | Wikipedia has a good historical description of the Open Source | ||
43 | Philosophy `here <http://en.wikipedia.org/wiki/Open_source>`__. You can | ||
44 | also find helpful information on how to participate in the Linux | ||
45 | Community | ||
46 | `here <https://www.kernel.org/doc/html/latest/process/index.html>`__. | ||
47 | |||
48 | The Development Host | ||
49 | ==================== | ||
50 | |||
51 | A development host or :term:`Build Host` is key to | ||
52 | using the Yocto Project. Because the goal of the Yocto Project is to | ||
53 | develop images or applications that run on embedded hardware, | ||
54 | development of those images and applications generally takes place on a | ||
55 | system not intended to run the software - the development host. | ||
56 | |||
57 | You need to set up a development host in order to use it with the Yocto | ||
58 | Project. Most find that it is best to have a native Linux machine | ||
59 | function as the development host. However, it is possible to use a | ||
60 | system that does not run Linux as its operating system as your | ||
61 | development host. When you have a Mac or Windows-based system, you can | ||
62 | set it up as the development host by using | ||
63 | `CROPS <https://github.com/crops/poky-container>`__, which leverages | ||
64 | `Docker Containers <https://www.docker.com/>`__. Once you take the steps | ||
65 | to set up a CROPS machine, you effectively have access to a shell | ||
66 | environment that is similar to what you see when using a Linux-based | ||
67 | development host. For the steps needed to set up a system using CROPS, | ||
68 | see the | ||
69 | ":ref:`dev-manual/start:setting up to use cross platforms (crops)`" | ||
70 | section in | ||
71 | the Yocto Project Development Tasks Manual. | ||
72 | |||
73 | If your development host is going to be a system that runs a Linux | ||
74 | distribution, steps still exist that you must take to prepare the system | ||
75 | for use with the Yocto Project. You need to be sure that the Linux | ||
76 | distribution on the system is one that supports the Yocto Project. You | ||
77 | also need to be sure that the correct set of host packages are installed | ||
78 | that allow development using the Yocto Project. For the steps needed to | ||
79 | set up a development host that runs Linux, see the | ||
80 | ":ref:`dev-manual/start:setting up a native linux host`" | ||
81 | section in the Yocto Project Development Tasks Manual. | ||
82 | |||
83 | Once your development host is set up to use the Yocto Project, several | ||
84 | methods exist for you to do work in the Yocto Project environment: | ||
85 | |||
86 | - *Command Lines, BitBake, and Shells:* Traditional development in the | ||
87 | Yocto Project involves using the :term:`OpenEmbedded Build System`, | ||
88 | which uses | ||
89 | BitBake, in a command-line environment from a shell on your | ||
90 | development host. You can accomplish this from a host that is a | ||
91 | native Linux machine or from a host that has been set up with CROPS. | ||
92 | Either way, you create, modify, and build images and applications all | ||
93 | within a shell-based environment using components and tools available | ||
94 | through your Linux distribution and the Yocto Project. | ||
95 | |||
96 | For a general flow of the build procedures, see the | ||
97 | ":ref:`dev-manual/common-tasks:building a simple image`" | ||
98 | section in the Yocto Project Development Tasks Manual. | ||
99 | |||
100 | - *Board Support Package (BSP) Development:* Development of BSPs | ||
101 | involves using the Yocto Project to create and test layers that allow | ||
102 | easy development of images and applications targeted for specific | ||
103 | hardware. To development BSPs, you need to take some additional steps | ||
104 | beyond what was described in setting up a development host. | ||
105 | |||
106 | The :doc:`/bsp-guide/index` provides BSP-related development | ||
107 | information. For specifics on development host preparation, see the | ||
108 | ":ref:`bsp-guide/bsp:preparing your build host to work with bsp layers`" | ||
109 | section in the Yocto Project Board Support Package (BSP) Developer's | ||
110 | Guide. | ||
111 | |||
112 | - *Kernel Development:* If you are going to be developing kernels using | ||
113 | the Yocto Project you likely will be using ``devtool``. A workflow | ||
114 | using ``devtool`` makes kernel development quicker by reducing | ||
115 | iteration cycle times. | ||
116 | |||
117 | The :doc:`/kernel-dev/index` provides kernel-related | ||
118 | development information. For specifics on development host | ||
119 | preparation, see the | ||
120 | ":ref:`kernel-dev/common:preparing the build host to work on the kernel`" | ||
121 | section in the Yocto Project Linux Kernel Development Manual. | ||
122 | |||
123 | - *Using Toaster:* The other Yocto Project development method that | ||
124 | involves an interface that effectively puts the Yocto Project into | ||
125 | the background is Toaster. Toaster provides an interface to the | ||
126 | OpenEmbedded build system. The interface enables you to configure and | ||
127 | run your builds. Information about builds is collected and stored in | ||
128 | a database. You can use Toaster to configure and start builds on | ||
129 | multiple remote build servers. | ||
130 | |||
131 | For steps that show you how to set up your development host to use | ||
132 | Toaster and on how to use Toaster in general, see the | ||
133 | :doc:`/toaster-manual/index`. | ||
134 | |||
135 | Yocto Project Source Repositories | ||
136 | ================================= | ||
137 | |||
138 | The Yocto Project team maintains complete source repositories for all | ||
139 | Yocto Project files at :yocto_git:`/`. This web-based source | ||
140 | code browser is organized into categories by function such as IDE | ||
141 | Plugins, Matchbox, Poky, Yocto Linux Kernel, and so forth. From the | ||
142 | interface, you can click on any particular item in the "Name" column and | ||
143 | see the URL at the bottom of the page that you need to clone a Git | ||
144 | repository for that particular item. Having a local Git repository of | ||
145 | the :term:`Source Directory`, which | ||
146 | is usually named "poky", allows you to make changes, contribute to the | ||
147 | history, and ultimately enhance the Yocto Project's tools, Board Support | ||
148 | Packages, and so forth. | ||
149 | |||
150 | For any supported release of Yocto Project, you can also go to the | ||
151 | :yocto_home:`Yocto Project Website <>` and select the "DOWNLOADS" | ||
152 | item from the "SOFTWARE" menu and get a released tarball of the ``poky`` | ||
153 | repository, any supported BSP tarball, or Yocto Project tools. Unpacking | ||
154 | these tarballs gives you a snapshot of the released files. | ||
155 | |||
156 | .. note:: | ||
157 | |||
158 | - The recommended method for setting up the Yocto Project | ||
159 | :term:`Source Directory` and the files | ||
160 | for supported BSPs (e.g., ``meta-intel``) is to use `Git <#git>`__ | ||
161 | to create a local copy of the upstream repositories. | ||
162 | |||
163 | - Be sure to always work in matching branches for both the selected | ||
164 | BSP repository and the Source Directory (i.e. ``poky``) | ||
165 | repository. For example, if you have checked out the "master" | ||
166 | branch of ``poky`` and you are going to use ``meta-intel``, be | ||
167 | sure to checkout the "master" branch of ``meta-intel``. | ||
168 | |||
169 | In summary, here is where you can get the project files needed for | ||
170 | development: | ||
171 | |||
172 | - :yocto_git:`Source Repositories: <>` This area contains IDE | ||
173 | Plugins, Matchbox, Poky, Poky Support, Tools, Yocto Linux Kernel, and | ||
174 | Yocto Metadata Layers. You can create local copies of Git | ||
175 | repositories for each of these areas. | ||
176 | |||
177 | .. image:: figures/source-repos.png | ||
178 | :align: center | ||
179 | |||
180 | For steps on how to view and access these upstream Git repositories, | ||
181 | see the ":ref:`dev-manual/start:accessing source repositories`" | ||
182 | Section in the Yocto Project Development Tasks Manual. | ||
183 | |||
184 | - :yocto_dl:`Index of /releases: </releases>` This is an index | ||
185 | of releases such as Poky, Pseudo, installers for cross-development | ||
186 | toolchains, miscellaneous support and all released versions of Yocto | ||
187 | Project in the form of images or tarballs. Downloading and extracting | ||
188 | these files does not produce a local copy of the Git repository but | ||
189 | rather a snapshot of a particular release or image. | ||
190 | |||
191 | .. image:: figures/index-downloads.png | ||
192 | :align: center | ||
193 | |||
194 | For steps on how to view and access these files, see the | ||
195 | ":ref:`dev-manual/start:accessing index of releases`" | ||
196 | section in the Yocto Project Development Tasks Manual. | ||
197 | |||
198 | - *"DOWNLOADS" page for the* :yocto_home:`Yocto Project Website <>` *:* | ||
199 | |||
200 | The Yocto Project website includes a "DOWNLOADS" page accessible | ||
201 | through the "SOFTWARE" menu that allows you to download any Yocto | ||
202 | Project release, tool, and Board Support Package (BSP) in tarball | ||
203 | form. The tarballs are similar to those found in the | ||
204 | :yocto_dl:`Index of /releases: </releases>` area. | ||
205 | |||
206 | .. image:: figures/yp-download.png | ||
207 | :align: center | ||
208 | |||
209 | For steps on how to use the "DOWNLOADS" page, see the | ||
210 | ":ref:`dev-manual/start:using the downloads page`" | ||
211 | section in the Yocto Project Development Tasks Manual. | ||
212 | |||
213 | Git Workflows and the Yocto Project | ||
214 | =================================== | ||
215 | |||
216 | Developing using the Yocto Project likely requires the use of | ||
217 | `Git <#git>`__. Git is a free, open source distributed version control | ||
218 | system used as part of many collaborative design environments. This | ||
219 | section provides workflow concepts using the Yocto Project and Git. In | ||
220 | particular, the information covers basic practices that describe roles | ||
221 | and actions in a collaborative development environment. | ||
222 | |||
223 | .. note:: | ||
224 | |||
225 | If you are familiar with this type of development environment, you | ||
226 | might not want to read this section. | ||
227 | |||
228 | The Yocto Project files are maintained using Git in "branches" whose Git | ||
229 | histories track every change and whose structures provide branches for | ||
230 | all diverging functionality. Although there is no need to use Git, many | ||
231 | open source projects do so. | ||
232 | |||
233 | For the Yocto Project, a key individual called the "maintainer" is | ||
234 | responsible for the integrity of the "master" branch of a given Git | ||
235 | repository. The "master" branch is the "upstream" repository from which | ||
236 | final or most recent builds of a project occur. The maintainer is | ||
237 | responsible for accepting changes from other developers and for | ||
238 | organizing the underlying branch structure to reflect release strategies | ||
239 | and so forth. | ||
240 | |||
241 | .. note:: | ||
242 | |||
243 | For information on finding out who is responsible for (maintains) a | ||
244 | particular area of code in the Yocto Project, see the | ||
245 | ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" | ||
246 | section of the Yocto Project Development Tasks Manual. | ||
247 | |||
248 | The Yocto Project ``poky`` Git repository also has an upstream | ||
249 | contribution Git repository named ``poky-contrib``. You can see all the | ||
250 | branches in this repository using the web interface of the | ||
251 | :yocto_git:`Source Repositories <>` organized within the "Poky Support" | ||
252 | area. These branches hold changes (commits) to the project that have | ||
253 | been submitted or committed by the Yocto Project development team and by | ||
254 | community members who contribute to the project. The maintainer | ||
255 | determines if the changes are qualified to be moved from the "contrib" | ||
256 | branches into the "master" branch of the Git repository. | ||
257 | |||
258 | Developers (including contributing community members) create and | ||
259 | maintain cloned repositories of upstream branches. The cloned | ||
260 | repositories are local to their development platforms and are used to | ||
261 | develop changes. When a developer is satisfied with a particular feature | ||
262 | or change, they "push" the change to the appropriate "contrib" | ||
263 | repository. | ||
264 | |||
265 | Developers are responsible for keeping their local repository up-to-date | ||
266 | with whatever upstream branch they are working against. They are also | ||
267 | responsible for straightening out any conflicts that might arise within | ||
268 | files that are being worked on simultaneously by more than one person. | ||
269 | All this work is done locally on the development host before anything is | ||
270 | pushed to a "contrib" area and examined at the maintainer's level. | ||
271 | |||
272 | A somewhat formal method exists by which developers commit changes and | ||
273 | push them into the "contrib" area and subsequently request that the | ||
274 | maintainer include them into an upstream branch. This process is called | ||
275 | "submitting a patch" or "submitting a change." For information on | ||
276 | submitting patches and changes, see the | ||
277 | ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" | ||
278 | section in the Yocto Project Development Tasks Manual. | ||
279 | |||
280 | In summary, a single point of entry exists for changes into a "master" | ||
281 | or development branch of the Git repository, which is controlled by the | ||
282 | project's maintainer. And, a set of developers exist who independently | ||
283 | develop, test, and submit changes to "contrib" areas for the maintainer | ||
284 | to examine. The maintainer then chooses which changes are going to | ||
285 | become a permanent part of the project. | ||
286 | |||
287 | .. image:: figures/git-workflow.png | ||
288 | :align: center | ||
289 | |||
290 | While each development environment is unique, there are some best | ||
291 | practices or methods that help development run smoothly. The following | ||
292 | list describes some of these practices. For more information about Git | ||
293 | workflows, see the workflow topics in the `Git Community | ||
294 | Book <http://book.git-scm.com>`__. | ||
295 | |||
296 | - *Make Small Changes:* It is best to keep the changes you commit small | ||
297 | as compared to bundling many disparate changes into a single commit. | ||
298 | This practice not only keeps things manageable but also allows the | ||
299 | maintainer to more easily include or refuse changes. | ||
300 | |||
301 | - *Make Complete Changes:* It is also good practice to leave the | ||
302 | repository in a state that allows you to still successfully build | ||
303 | your project. In other words, do not commit half of a feature, then | ||
304 | add the other half as a separate, later commit. Each commit should | ||
305 | take you from one buildable project state to another buildable state. | ||
306 | |||
307 | - *Use Branches Liberally:* It is very easy to create, use, and delete | ||
308 | local branches in your working Git repository on the development | ||
309 | host. You can name these branches anything you like. It is helpful to | ||
310 | give them names associated with the particular feature or change on | ||
311 | which you are working. Once you are done with a feature or change and | ||
312 | have merged it into your local master branch, simply discard the | ||
313 | temporary branch. | ||
314 | |||
315 | - *Merge Changes:* The ``git merge`` command allows you to take the | ||
316 | changes from one branch and fold them into another branch. This | ||
317 | process is especially helpful when more than a single developer might | ||
318 | be working on different parts of the same feature. Merging changes | ||
319 | also automatically identifies any collisions or "conflicts" that | ||
320 | might happen as a result of the same lines of code being altered by | ||
321 | two different developers. | ||
322 | |||
323 | - *Manage Branches:* Because branches are easy to use, you should use a | ||
324 | system where branches indicate varying levels of code readiness. For | ||
325 | example, you can have a "work" branch to develop in, a "test" branch | ||
326 | where the code or change is tested, a "stage" branch where changes | ||
327 | are ready to be committed, and so forth. As your project develops, | ||
328 | you can merge code across the branches to reflect ever-increasing | ||
329 | stable states of the development. | ||
330 | |||
331 | - *Use Push and Pull:* The push-pull workflow is based on the concept | ||
332 | of developers "pushing" local commits to a remote repository, which | ||
333 | is usually a contribution repository. This workflow is also based on | ||
334 | developers "pulling" known states of the project down into their | ||
335 | local development repositories. The workflow easily allows you to | ||
336 | pull changes submitted by other developers from the upstream | ||
337 | repository into your work area ensuring that you have the most recent | ||
338 | software on which to develop. The Yocto Project has two scripts named | ||
339 | ``create-pull-request`` and ``send-pull-request`` that ship with the | ||
340 | release to facilitate this workflow. You can find these scripts in | ||
341 | the ``scripts`` folder of the | ||
342 | :term:`Source Directory`. For information | ||
343 | on how to use these scripts, see the | ||
344 | ":ref:`dev-manual/common-tasks:using scripts to push a change upstream and request a pull`" | ||
345 | section in the Yocto Project Development Tasks Manual. | ||
346 | |||
347 | - *Patch Workflow:* This workflow allows you to notify the maintainer | ||
348 | through an email that you have a change (or patch) you would like | ||
349 | considered for the "master" branch of the Git repository. To send | ||
350 | this type of change, you format the patch and then send the email | ||
351 | using the Git commands ``git format-patch`` and ``git send-email``. | ||
352 | For information on how to use these scripts, see the | ||
353 | ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" | ||
354 | section in the Yocto Project Development Tasks Manual. | ||
355 | |||
356 | Git | ||
357 | === | ||
358 | |||
359 | The Yocto Project makes extensive use of Git, which is a free, open | ||
360 | source distributed version control system. Git supports distributed | ||
361 | development, non-linear development, and can handle large projects. It | ||
362 | is best that you have some fundamental understanding of how Git tracks | ||
363 | projects and how to work with Git if you are going to use the Yocto | ||
364 | Project for development. This section provides a quick overview of how | ||
365 | Git works and provides you with a summary of some essential Git | ||
366 | commands. | ||
367 | |||
368 | .. note:: | ||
369 | |||
370 | - For more information on Git, see | ||
371 | http://git-scm.com/documentation. | ||
372 | |||
373 | - If you need to download Git, it is recommended that you add Git to | ||
374 | your system through your distribution's "software store" (e.g. for | ||
375 | Ubuntu, use the Ubuntu Software feature). For the Git download | ||
376 | page, see http://git-scm.com/download. | ||
377 | |||
378 | - For information beyond the introductory nature in this section, | ||
379 | see the ":ref:`dev-manual/start:locating yocto project source files`" | ||
380 | section in the Yocto Project Development Tasks Manual. | ||
381 | |||
382 | Repositories, Tags, and Branches | ||
383 | -------------------------------- | ||
384 | |||
385 | As mentioned briefly in the previous section and also in the "`Git | ||
386 | Workflows and the Yocto | ||
387 | Project <#gs-git-workflows-and-the-yocto-project>`__" section, the Yocto | ||
388 | Project maintains source repositories at :yocto_git:`/`. If you | ||
389 | look at this web-interface of the repositories, each item is a separate | ||
390 | Git repository. | ||
391 | |||
392 | Git repositories use branching techniques that track content change (not | ||
393 | files) within a project (e.g. a new feature or updated documentation). | ||
394 | Creating a tree-like structure based on project divergence allows for | ||
395 | excellent historical information over the life of a project. This | ||
396 | methodology also allows for an environment from which you can do lots of | ||
397 | local experimentation on projects as you develop changes or new | ||
398 | features. | ||
399 | |||
400 | A Git repository represents all development efforts for a given project. | ||
401 | For example, the Git repository ``poky`` contains all changes and | ||
402 | developments for that repository over the course of its entire life. | ||
403 | That means that all changes that make up all releases are captured. The | ||
404 | repository maintains a complete history of changes. | ||
405 | |||
406 | You can create a local copy of any repository by "cloning" it with the | ||
407 | ``git clone`` command. When you clone a Git repository, you end up with | ||
408 | an identical copy of the repository on your development system. Once you | ||
409 | have a local copy of a repository, you can take steps to develop | ||
410 | locally. For examples on how to clone Git repositories, see the | ||
411 | ":ref:`dev-manual/start:locating yocto project source files`" | ||
412 | section in the Yocto Project Development Tasks Manual. | ||
413 | |||
414 | It is important to understand that Git tracks content change and not | ||
415 | files. Git uses "branches" to organize different development efforts. | ||
416 | For example, the ``poky`` repository has several branches that include | ||
417 | the current "&DISTRO_NAME_NO_CAP;" branch, the "master" branch, and many | ||
418 | branches for past Yocto Project releases. You can see all the branches | ||
419 | by going to :yocto_git:`/poky/` and clicking on the | ||
420 | ``[...]`` link beneath the "Branch" heading. | ||
421 | |||
422 | Each of these branches represents a specific area of development. The | ||
423 | "master" branch represents the current or most recent development. All | ||
424 | other branches represent offshoots of the "master" branch. | ||
425 | |||
426 | When you create a local copy of a Git repository, the copy has the same | ||
427 | set of branches as the original. This means you can use Git to create a | ||
428 | local working area (also called a branch) that tracks a specific | ||
429 | development branch from the upstream source Git repository. in other | ||
430 | words, you can define your local Git environment to work on any | ||
431 | development branch in the repository. To help illustrate, consider the | ||
432 | following example Git commands: | ||
433 | :: | ||
434 | |||
435 | $ cd ~ | ||
436 | $ git clone git://git.yoctoproject.org/poky | ||
437 | $ cd poky | ||
438 | $ git checkout -b &DISTRO_NAME_NO_CAP; origin/&DISTRO_NAME_NO_CAP; | ||
439 | |||
440 | In the previous example | ||
441 | after moving to the home directory, the ``git clone`` command creates a | ||
442 | local copy of the upstream ``poky`` Git repository. By default, Git | ||
443 | checks out the "master" branch for your work. After changing the working | ||
444 | directory to the new local repository (i.e. ``poky``), the | ||
445 | ``git checkout`` command creates and checks out a local branch named | ||
446 | "&DISTRO_NAME_NO_CAP;", which tracks the upstream | ||
447 | "origin/&DISTRO_NAME_NO_CAP;" branch. Changes you make while in this | ||
448 | branch would ultimately affect the upstream "&DISTRO_NAME_NO_CAP;" branch | ||
449 | of the ``poky`` repository. | ||
450 | |||
451 | It is important to understand that when you create and checkout a local | ||
452 | working branch based on a branch name, your local environment matches | ||
453 | the "tip" of that particular development branch at the time you created | ||
454 | your local branch, which could be different from the files in the | ||
455 | "master" branch of the upstream repository. In other words, creating and | ||
456 | checking out a local branch based on the "&DISTRO_NAME_NO_CAP;" branch | ||
457 | name is not the same as checking out the "master" branch in the | ||
458 | repository. Keep reading to see how you create a local snapshot of a | ||
459 | Yocto Project Release. | ||
460 | |||
461 | Git uses "tags" to mark specific changes in a repository branch | ||
462 | structure. Typically, a tag is used to mark a special point such as the | ||
463 | final change (or commit) before a project is released. You can see the | ||
464 | tags used with the ``poky`` Git repository by going to :yocto_git:`/poky/` | ||
465 | and clicking on the ``[...]`` link beneath the "Tag" heading. | ||
466 | |||
467 | Some key tags for the ``poky`` repository are ``jethro-14.0.3``, | ||
468 | ``morty-16.0.1``, ``pyro-17.0.0``, and | ||
469 | ``&DISTRO_NAME_NO_CAP;-&POKYVERSION;``. These tags represent Yocto Project | ||
470 | releases. | ||
471 | |||
472 | When you create a local copy of the Git repository, you also have access | ||
473 | to all the tags in the upstream repository. Similar to branches, you can | ||
474 | create and checkout a local working Git branch based on a tag name. When | ||
475 | you do this, you get a snapshot of the Git repository that reflects the | ||
476 | state of the files when the change was made associated with that tag. | ||
477 | The most common use is to checkout a working branch that matches a | ||
478 | specific Yocto Project release. Here is an example: | ||
479 | :: | ||
480 | |||
481 | $ cd ~ | ||
482 | $ git clone git://git.yoctoproject.org/poky | ||
483 | $ cd poky | ||
484 | $ git fetch --tags | ||
485 | $ git checkout tags/rocko-18.0.0 -b my_rocko-18.0.0 | ||
486 | |||
487 | In this example, the name | ||
488 | of the top-level directory of your local Yocto Project repository is | ||
489 | ``poky``. After moving to the ``poky`` directory, the ``git fetch`` | ||
490 | command makes all the upstream tags available locally in your | ||
491 | repository. Finally, the ``git checkout`` command creates and checks out | ||
492 | a branch named "my-rocko-18.0.0" that is based on the upstream branch | ||
493 | whose "HEAD" matches the commit in the repository associated with the | ||
494 | "rocko-18.0.0" tag. The files in your repository now exactly match that | ||
495 | particular Yocto Project release as it is tagged in the upstream Git | ||
496 | repository. It is important to understand that when you create and | ||
497 | checkout a local working branch based on a tag, your environment matches | ||
498 | a specific point in time and not the entire development branch (i.e. | ||
499 | from the "tip" of the branch backwards). | ||
500 | |||
501 | Basic Commands | ||
502 | -------------- | ||
503 | |||
504 | Git has an extensive set of commands that lets you manage changes and | ||
505 | perform collaboration over the life of a project. Conveniently though, | ||
506 | you can manage with a small set of basic operations and workflows once | ||
507 | you understand the basic philosophy behind Git. You do not have to be an | ||
508 | expert in Git to be functional. A good place to look for instruction on | ||
509 | a minimal set of Git commands is | ||
510 | `here <http://git-scm.com/documentation>`__. | ||
511 | |||
512 | The following list of Git commands briefly describes some basic Git | ||
513 | operations as a way to get started. As with any set of commands, this | ||
514 | list (in most cases) simply shows the base command and omits the many | ||
515 | arguments it supports. See the Git documentation for complete | ||
516 | descriptions and strategies on how to use these commands: | ||
517 | |||
518 | - *git init:* Initializes an empty Git repository. You cannot use | ||
519 | Git commands unless you have a ``.git`` repository. | ||
520 | |||
521 | - *git clone:* Creates a local clone of a Git repository that is on | ||
522 | equal footing with a fellow developer's Git repository or an upstream | ||
523 | repository. | ||
524 | |||
525 | - *git add:* Locally stages updated file contents to the index that | ||
526 | Git uses to track changes. You must stage all files that have changed | ||
527 | before you can commit them. | ||
528 | |||
529 | - *git commit:* Creates a local "commit" that documents the changes | ||
530 | you made. Only changes that have been staged can be committed. | ||
531 | Commits are used for historical purposes, for determining if a | ||
532 | maintainer of a project will allow the change, and for ultimately | ||
533 | pushing the change from your local Git repository into the project's | ||
534 | upstream repository. | ||
535 | |||
536 | - *git status:* Reports any modified files that possibly need to be | ||
537 | staged and gives you a status of where you stand regarding local | ||
538 | commits as compared to the upstream repository. | ||
539 | |||
540 | - *git checkout branch-name:* Changes your local working branch and | ||
541 | in this form assumes the local branch already exists. This command is | ||
542 | analogous to "cd". | ||
543 | |||
544 | - *git checkout –b working-branch upstream-branch:* Creates and | ||
545 | checks out a working branch on your local machine. The local branch | ||
546 | tracks the upstream branch. You can use your local branch to isolate | ||
547 | your work. It is a good idea to use local branches when adding | ||
548 | specific features or changes. Using isolated branches facilitates | ||
549 | easy removal of changes if they do not work out. | ||
550 | |||
551 | - *git branch:* Displays the existing local branches associated | ||
552 | with your local repository. The branch that you have currently | ||
553 | checked out is noted with an asterisk character. | ||
554 | |||
555 | - *git branch -D branch-name:* Deletes an existing local branch. | ||
556 | You need to be in a local branch other than the one you are deleting | ||
557 | in order to delete branch-name. | ||
558 | |||
559 | - *git pull --rebase:* Retrieves information from an upstream Git | ||
560 | repository and places it in your local Git repository. You use this | ||
561 | command to make sure you are synchronized with the repository from | ||
562 | which you are basing changes (.e.g. the "master" branch). The | ||
563 | "--rebase" option ensures that any local commits you have in your | ||
564 | branch are preserved at the top of your local branch. | ||
565 | |||
566 | - *git push repo-name local-branch:upstream-branch:* Sends | ||
567 | all your committed local changes to the upstream Git repository that | ||
568 | your local repository is tracking (e.g. a contribution repository). | ||
569 | The maintainer of the project draws from these repositories to merge | ||
570 | changes (commits) into the appropriate branch of project's upstream | ||
571 | repository. | ||
572 | |||
573 | - *git merge:* Combines or adds changes from one local branch of | ||
574 | your repository with another branch. When you create a local Git | ||
575 | repository, the default branch is named "master". A typical workflow | ||
576 | is to create a temporary branch that is based off "master" that you | ||
577 | would use for isolated work. You would make your changes in that | ||
578 | isolated branch, stage and commit them locally, switch to the | ||
579 | "master" branch, and then use the ``git merge`` command to apply the | ||
580 | changes from your isolated branch into the currently checked out | ||
581 | branch (e.g. "master"). After the merge is complete and if you are | ||
582 | done with working in that isolated branch, you can safely delete the | ||
583 | isolated branch. | ||
584 | |||
585 | - *git cherry-pick commits:* Choose and apply specific commits from | ||
586 | one branch into another branch. There are times when you might not be | ||
587 | able to merge all the changes in one branch with another but need to | ||
588 | pick out certain ones. | ||
589 | |||
590 | - *gitk:* Provides a GUI view of the branches and changes in your | ||
591 | local Git repository. This command is a good way to graphically see | ||
592 | where things have diverged in your local repository. | ||
593 | |||
594 | .. note:: | ||
595 | |||
596 | You need to install the | ||
597 | gitk | ||
598 | package on your development system to use this command. | ||
599 | |||
600 | - *git log:* Reports a history of your commits to the repository. | ||
601 | This report lists all commits regardless of whether you have pushed | ||
602 | them upstream or not. | ||
603 | |||
604 | - *git diff:* Displays line-by-line differences between a local | ||
605 | working file and the same file as understood by Git. This command is | ||
606 | useful to see what you have changed in any given file. | ||
607 | |||
608 | Licensing | ||
609 | ========= | ||
610 | |||
611 | Because open source projects are open to the public, they have different | ||
612 | licensing structures in place. License evolution for both Open Source | ||
613 | and Free Software has an interesting history. If you are interested in | ||
614 | this history, you can find basic information here: | ||
615 | |||
616 | - `Open source license | ||
617 | history <http://en.wikipedia.org/wiki/Open-source_license>`__ | ||
618 | |||
619 | - `Free software license | ||
620 | history <http://en.wikipedia.org/wiki/Free_software_license>`__ | ||
621 | |||
622 | In general, the Yocto Project is broadly licensed under the | ||
623 | Massachusetts Institute of Technology (MIT) License. MIT licensing | ||
624 | permits the reuse of software within proprietary software as long as the | ||
625 | license is distributed with that software. MIT is also compatible with | ||
626 | the GNU General Public License (GPL). Patches to the Yocto Project | ||
627 | follow the upstream licensing scheme. You can find information on the | ||
628 | MIT license | ||
629 | `here <http://www.opensource.org/licenses/mit-license.php>`__. You can | ||
630 | find information on the GNU GPL | ||
631 | `here <http://www.opensource.org/licenses/LGPL-3.0>`__. | ||
632 | |||
633 | When you build an image using the Yocto Project, the build process uses | ||
634 | a known list of licenses to ensure compliance. You can find this list in | ||
635 | the :term:`Source Directory` at | ||
636 | ``meta/files/common-licenses``. Once the build completes, the list of | ||
637 | all licenses found and used during that build are kept in the | ||
638 | :term:`Build Directory` at | ||
639 | ``tmp/deploy/licenses``. | ||
640 | |||
641 | If a module requires a license that is not in the base list, the build | ||
642 | process generates a warning during the build. These tools make it easier | ||
643 | for a developer to be certain of the licenses with which their shipped | ||
644 | products must comply. However, even with these tools it is still up to | ||
645 | the developer to resolve potential licensing issues. | ||
646 | |||
647 | The base list of licenses used by the build process is a combination of | ||
648 | the Software Package Data Exchange (SPDX) list and the Open Source | ||
649 | Initiative (OSI) projects. `SPDX Group <http://spdx.org>`__ is a working | ||
650 | group of the Linux Foundation that maintains a specification for a | ||
651 | standard format for communicating the components, licenses, and | ||
652 | copyrights associated with a software package. | ||
653 | `OSI <http://opensource.org>`__ is a corporation dedicated to the Open | ||
654 | Source Definition and the effort for reviewing and approving licenses | ||
655 | that conform to the Open Source Definition (OSD). | ||
656 | |||
657 | You can find a list of the combined SPDX and OSI licenses that the Yocto | ||
658 | Project uses in the ``meta/files/common-licenses`` directory in your | ||
659 | :term:`Source Directory`. | ||
660 | |||
661 | For information that can help you maintain compliance with various open | ||
662 | source licensing during the lifecycle of a product created using the | ||
663 | Yocto Project, see the | ||
664 | ":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`" | ||
665 | section in the Yocto Project Development Tasks Manual. | ||