diff --git a/documentation/ref-manual/usingpoky.xml b/documentation/ref-manual/usingpoky.xml index 030448df0b..41f872c07e 100644 --- a/documentation/ref-manual/usingpoky.xml +++ b/documentation/ref-manual/usingpoky.xml @@ -89,145 +89,6 @@ -
- Speeding Up the Build - - - Build time can be an issue. - By default, the build system uses three simple controls to try and - maximize build efficiency: - - - BB_NUMBER_THREADS - - - BB_NUMBER_PARSE_THREADS - - - PARALLEL_MAKE - - - These three variables all scale to the number of processor cores - available on the build system. - This auto-scaling ensures that the build system fundamentally takes - advantage of potential parallel operations during the build - based on the build machine's capabilities. - - - - If you need to achieve even faster builds than what the build system - produces by default, you can consider and implement some of the - following: - - - BB_NUMBER_THREADS, - BB_NUMBER_PARSE_THREADS, and - PARALLEL_MAKE: - As previously mentioned, the build system scales the values - for these variables. - However, you can manually override them in your - local.conf file if you are not satisfied - with the defaults. - - - File system type: - The file system type that the build is being performed on can - also influence performance. - Using ext4 is recommended as compared - to ext2 and ext3 - due to ext4 improved features - such as extents. - - - Disabling the updating of access time using - noatime: - The noatime mount option prevents the - build system from updating file and directory access times. - - - Setting a longer commit: - Richard - I need some sort of general summary here about this. - I don't know the context. - - - The packaging backend: - Of the available packaging backends, IPK is the fastest. - Additionally, selecting a singular packaging backend also - helps. - - - Using /tmp as a temporary file system: - While this can help speed up the build, the benefits are - limited due to the compiler using - -pipe. - The build system goes to some lengths to avoid - sync() calls into the - file system on the principle that if there was a significant - failure, the - Build Directory - contents could easily be rebuilt. - - - Inheriting the - rm_work - class: - Inheriting this class has shown to speed up builds due to - significantly lower amounts of data stored in the data - cache as well as on disk. - Inheriting this class also makes cleanup of - TMPDIR - faster, at the expense of being easily able to dive into the - source code. - File system maintainers have recommended that the fastest way - to clean up large numbers of files is to reformat partitions - rather than delete files due to the linear nature of partitions. - This, of course, assumes you structure the disk partitions and - file systems in a way that this is practical. - - - Aside from the previous list, you should keep some trade offs in - mind that can help you speed up the build: - - - Exclude debug symbols and other debug information: - If you do not need these symbols and other debug information, - disabling the *-dbg package generation - can speed up the build. - You can disable this generation by setting the - INHIBIT_PACKAGE_DEBUG_SPLIT - variable to "1". - - - Disable static library generation for recipes derived from - autoconf or libtool: - Following is an example showing how to disable static - libraries and still provide an override to handle exceptions: - - STATICLIBCONF = "--disable-static" - STATICLIBCONF_sqlite3-native = "" - EXTRA_OECONF += "${STATICLIBCONF}" - - Notes - - - Some recipes need static libraries in order to work - correctly (e.g. pseudo-native - needs sqlite3-native). - Overrides, as in the previous example, account for - these kinds of exceptions. - - - Some packages have packaging code that assumes the - presence of the static libraries. - If so, you might need to exclude them as well. - - - - - - -
-
Installing and Using the Result @@ -1027,6 +888,148 @@
+
+ Speeding Up the Build + + + Build time can be an issue. + By default, the build system uses three simple controls to try and + maximize build efficiency: + + + BB_NUMBER_THREADS + + + BB_NUMBER_PARSE_THREADS + + + PARALLEL_MAKE + + + These three variables all scale to the number of processor cores + available on the build system. + This auto-scaling ensures that the build system fundamentally takes + advantage of potential parallel operations during the build + based on the build machine's capabilities. + + + + If you need to achieve even faster builds than what the build system + produces by default, you can consider and implement some of the + following: + + + BB_NUMBER_THREADS, + BB_NUMBER_PARSE_THREADS, and + PARALLEL_MAKE: + As previously mentioned, the build system scales the values + for these variables. + However, you can manually override them in your + local.conf file if you are not satisfied + with the defaults. + + + File system type: + The file system type that the build is being performed on can + also influence performance. + Using ext4 is recommended as compared + to ext2 and ext3 + due to ext4 improved features + such as extents. + + + Disabling the updating of access time using + noatime: + The noatime mount option prevents the + build system from updating file and directory access times. + + + Setting a longer commit: + Using the "commit=" mount option increases the interval + in seconds between disk cache writes. + Changing this interval from the five second default to + something longer increases the risk of data loss but decreases + the need to write to the disk, thus increasing the build + performance. + + + Choosing the packaging backend: + Of the available packaging backends, IPK is the fastest. + Additionally, selecting a singular packaging backend also + helps. + + + Using /tmp as a temporary file system: + While this can help speed up the build, the benefits are + limited due to the compiler using + -pipe. + The build system goes to some lengths to avoid + sync() calls into the + file system on the principle that if there was a significant + failure, the + Build Directory + contents could easily be rebuilt. + + + Inheriting the + rm_work + class: + Inheriting this class has shown to speed up builds due to + significantly lower amounts of data stored in the data + cache as well as on disk. + Inheriting this class also makes cleanup of + TMPDIR + faster, at the expense of being easily able to dive into the + source code. + File system maintainers have recommended that the fastest way + to clean up large numbers of files is to reformat partitions + rather than delete files due to the linear nature of partitions. + This, of course, assumes you structure the disk partitions and + file systems in a way that this is practical. + + + Aside from the previous list, you should keep some trade offs in + mind that can help you speed up the build: + + + Exclude debug symbols and other debug information: + If you do not need these symbols and other debug information, + disabling the *-dbg package generation + can speed up the build. + You can disable this generation by setting the + INHIBIT_PACKAGE_DEBUG_SPLIT + variable to "1". + + + Disable static library generation for recipes derived from + autoconf or libtool: + Following is an example showing how to disable static + libraries and still provide an override to handle exceptions: + + STATICLIBCONF = "--disable-static" + STATICLIBCONF_sqlite3-native = "" + EXTRA_OECONF += "${STATICLIBCONF}" + + Notes + + + Some recipes need static libraries in order to work + correctly (e.g. pseudo-native + needs sqlite3-native). + Overrides, as in the previous example, account for + these kinds of exceptions. + + + Some packages have packaging code that assumes the + presence of the static libraries. + If so, you might need to exclude them as well. + + + + + + +