diff options
| author | Scott Rifenbark <srifenbark@gmail.com> | 2018-01-23 11:29:22 -0800 |
|---|---|---|
| committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2018-02-14 15:25:29 +0000 |
| commit | 30b91e6d891fbfa6a44487a27b8ceb5618157614 (patch) | |
| tree | a55464032253d643fc4ceec7952cc32e656fdc26 /documentation/dev-manual | |
| parent | 355103f8cf2295fb2de91ce25a084e286bdeadeb (diff) | |
| download | poky-30b91e6d891fbfa6a44487a27b8ceb5618157614.tar.gz | |
documentation: Removed "usingpoky" chapter from ref-manual
Fixes [YOCTO #12370]
All of the information from the "usingpoky" chapter in the
ref-manual has been distributed out over the rest of the
YP manual set. Primarily, this information went into the
dev-manual and the overview-manual. Because the chapter is
no more, I had to update the mega-manual.xml to not include that
chapter. Also, had to update ref-manual to exclude the chapter
as part of the Make process.
(From yocto-docs rev: b988cab06d42f0ac2220cefe66949c5ab6cbf803)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/dev-manual')
| -rw-r--r-- | documentation/dev-manual/dev-manual-start.xml | 165 |
1 files changed, 165 insertions, 0 deletions
diff --git a/documentation/dev-manual/dev-manual-start.xml b/documentation/dev-manual/dev-manual-start.xml index 02635f4127..21f5e9ed5e 100644 --- a/documentation/dev-manual/dev-manual-start.xml +++ b/documentation/dev-manual/dev-manual-start.xml | |||
| @@ -840,6 +840,171 @@ | |||
| 840 | </orderedlist> | 840 | </orderedlist> |
| 841 | </para> | 841 | </para> |
| 842 | </section> | 842 | </section> |
| 843 | |||
| 844 | <section id='speeding-up-the-build'> | ||
| 845 | <title>Speeding Up the Build</title> | ||
| 846 | |||
| 847 | <para> | ||
| 848 | Build time can be an issue. | ||
| 849 | By default, the build system uses simple controls to try and maximize | ||
| 850 | build efficiency. | ||
| 851 | In general, the default settings for all the following variables | ||
| 852 | result in the most efficient build times when dealing with single | ||
| 853 | socket systems (i.e. a single CPU). | ||
| 854 | If you have multiple CPUs, you might try increasing the default | ||
| 855 | values to gain more speed. | ||
| 856 | See the descriptions in the glossary for each variable for more | ||
| 857 | information: | ||
| 858 | <itemizedlist> | ||
| 859 | <listitem><para> | ||
| 860 | <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename>:</link> | ||
| 861 | The maximum number of threads BitBake simultaneously executes. | ||
| 862 | </para></listitem> | ||
| 863 | <listitem><para> | ||
| 864 | <ulink url='&YOCTO_DOCS_BB_URL;#var-BB_NUMBER_PARSE_THREADS'><filename>BB_NUMBER_PARSE_THREADS</filename>:</ulink> | ||
| 865 | The number of threads BitBake uses during parsing. | ||
| 866 | </para></listitem> | ||
| 867 | <listitem><para> | ||
| 868 | <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename>:</link> | ||
| 869 | Extra options passed to the <filename>make</filename> command | ||
| 870 | during the | ||
| 871 | <link linkend='ref-tasks-compile'><filename>do_compile</filename></link> | ||
| 872 | task in order to specify parallel compilation on the | ||
| 873 | local build host. | ||
| 874 | </para></listitem> | ||
| 875 | <listitem><para> | ||
| 876 | <link linkend='var-PARALLEL_MAKEINST'><filename>PARALLEL_MAKEINST</filename>:</link> | ||
| 877 | Extra options passed to the <filename>make</filename> command | ||
| 878 | during the | ||
| 879 | <link linkend='ref-tasks-install'><filename>do_install</filename></link> | ||
| 880 | task in order to specify parallel installation on the | ||
| 881 | local build host. | ||
| 882 | </para></listitem> | ||
| 883 | </itemizedlist> | ||
| 884 | As mentioned, these variables all scale to the number of processor | ||
| 885 | cores available on the build system. | ||
| 886 | For single socket systems, this auto-scaling ensures that the build | ||
| 887 | system fundamentally takes advantage of potential parallel operations | ||
| 888 | during the build based on the build machine's capabilities. | ||
| 889 | </para> | ||
| 890 | |||
| 891 | <para> | ||
| 892 | Following are additional factors that can affect build speed: | ||
| 893 | <itemizedlist> | ||
| 894 | <listitem><para> | ||
| 895 | File system type: | ||
| 896 | The file system type that the build is being performed on can | ||
| 897 | also influence performance. | ||
| 898 | Using <filename>ext4</filename> is recommended as compared | ||
| 899 | to <filename>ext2</filename> and <filename>ext3</filename> | ||
| 900 | due to <filename>ext4</filename> improved features | ||
| 901 | such as extents. | ||
| 902 | </para></listitem> | ||
| 903 | <listitem><para> | ||
| 904 | Disabling the updating of access time using | ||
| 905 | <filename>noatime</filename>: | ||
| 906 | The <filename>noatime</filename> mount option prevents the | ||
| 907 | build system from updating file and directory access times. | ||
| 908 | </para></listitem> | ||
| 909 | <listitem><para> | ||
| 910 | Setting a longer commit: | ||
| 911 | Using the "commit=" mount option increases the interval | ||
| 912 | in seconds between disk cache writes. | ||
| 913 | Changing this interval from the five second default to | ||
| 914 | something longer increases the risk of data loss but decreases | ||
| 915 | the need to write to the disk, thus increasing the build | ||
| 916 | performance. | ||
| 917 | </para></listitem> | ||
| 918 | <listitem><para> | ||
| 919 | Choosing the packaging backend: | ||
| 920 | Of the available packaging backends, IPK is the fastest. | ||
| 921 | Additionally, selecting a singular packaging backend also | ||
| 922 | helps. | ||
| 923 | </para></listitem> | ||
| 924 | <listitem><para> | ||
| 925 | Using <filename>tmpfs</filename> for | ||
| 926 | <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> | ||
| 927 | as a temporary file system: | ||
| 928 | While this can help speed up the build, the benefits are | ||
| 929 | limited due to the compiler using | ||
| 930 | <filename>-pipe</filename>. | ||
| 931 | The build system goes to some lengths to avoid | ||
| 932 | <filename>sync()</filename> calls into the | ||
| 933 | file system on the principle that if there was a significant | ||
| 934 | failure, the | ||
| 935 | <link linkend='build-directory'>Build Directory</link> | ||
| 936 | contents could easily be rebuilt. | ||
| 937 | </para></listitem> | ||
| 938 | <listitem><para> | ||
| 939 | Inheriting the | ||
| 940 | <link linkend='ref-classes-rm-work'><filename>rm_work</filename></link> | ||
| 941 | class: | ||
| 942 | Inheriting this class has shown to speed up builds due to | ||
| 943 | significantly lower amounts of data stored in the data | ||
| 944 | cache as well as on disk. | ||
| 945 | Inheriting this class also makes cleanup of | ||
| 946 | <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> | ||
| 947 | faster, at the expense of being easily able to dive into the | ||
| 948 | source code. | ||
| 949 | File system maintainers have recommended that the fastest way | ||
| 950 | to clean up large numbers of files is to reformat partitions | ||
| 951 | rather than delete files due to the linear nature of partitions. | ||
| 952 | This, of course, assumes you structure the disk partitions and | ||
| 953 | file systems in a way that this is practical. | ||
| 954 | </para></listitem> | ||
| 955 | </itemizedlist> | ||
| 956 | Aside from the previous list, you should keep some trade offs in | ||
| 957 | mind that can help you speed up the build: | ||
| 958 | <itemizedlist> | ||
| 959 | <listitem><para> | ||
| 960 | Remove items from | ||
| 961 | <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link> | ||
| 962 | that you might not need. | ||
| 963 | </para></listitem> | ||
| 964 | <listitem><para> | ||
| 965 | Exclude debug symbols and other debug information: | ||
| 966 | If you do not need these symbols and other debug information, | ||
| 967 | disabling the <filename>*-dbg</filename> package generation | ||
| 968 | can speed up the build. | ||
| 969 | You can disable this generation by setting the | ||
| 970 | <link linkend='var-INHIBIT_PACKAGE_DEBUG_SPLIT'><filename>INHIBIT_PACKAGE_DEBUG_SPLIT</filename></link> | ||
| 971 | variable to "1". | ||
| 972 | </para></listitem> | ||
| 973 | <listitem><para> | ||
| 974 | Disable static library generation for recipes derived from | ||
| 975 | <filename>autoconf</filename> or <filename>libtool</filename>: | ||
| 976 | Following is an example showing how to disable static | ||
| 977 | libraries and still provide an override to handle exceptions: | ||
| 978 | <literallayout class='monospaced'> | ||
| 979 | STATICLIBCONF = "--disable-static" | ||
| 980 | STATICLIBCONF_sqlite3-native = "" | ||
| 981 | EXTRA_OECONF += "${STATICLIBCONF}" | ||
| 982 | </literallayout> | ||
| 983 | <note><title>Notes</title> | ||
| 984 | <itemizedlist> | ||
| 985 | <listitem><para> | ||
| 986 | Some recipes need static libraries in order to work | ||
| 987 | correctly (e.g. <filename>pseudo-native</filename> | ||
| 988 | needs <filename>sqlite3-native</filename>). | ||
| 989 | Overrides, as in the previous example, account for | ||
| 990 | these kinds of exceptions. | ||
| 991 | </para></listitem> | ||
| 992 | <listitem><para> | ||
| 993 | Some packages have packaging code that assumes the | ||
| 994 | presence of the static libraries. | ||
| 995 | If so, you might need to exclude them as well. | ||
| 996 | </para></listitem> | ||
| 997 | </itemizedlist> | ||
| 998 | </note> | ||
| 999 | </para></listitem> | ||
| 1000 | </itemizedlist> | ||
| 1001 | </para> | ||
| 1002 | </section> | ||
| 1003 | |||
| 1004 | |||
| 1005 | |||
| 1006 | |||
| 1007 | |||
| 843 | </chapter> | 1008 | </chapter> |
| 844 | <!-- | 1009 | <!-- |
| 845 | vim: expandtab tw=80 ts=4 | 1010 | vim: expandtab tw=80 ts=4 |
