Yocto Project - User contributions [en]

Ptest

2013-04-11T13:10:32Z

BjornStenberg:

=Introduction=

Ptest (''package test'') is a concept for building, installing and running the test suites that are included in many packages, and producing a consistent output format.

=Adding ptest to your build=

Ptest is enabled in two parts:

# Adding "ptest" to your DISTRO_FEATURES variable causes -ptest packages to be built.
# Adding "ptest-pkgs" to IMAGE_FEATURES variable causes -ptest packages to be installed in your image.

All ptest files are installed in /usr/lib/<package>/ptest.

=Running ptest=

The "ptest-runner" package installs a "ptest-runner" shell script which loops through all installed ptest test suites and runs them in sequence. You may therefore want to add "ptest-runner" to your image.

=Implementing ptest in a package recipe=

==What constitutes a ptest?==

A ptest must at minimum contain two things: run-ptest and the actual test.

run-ptest is a minimal shell script that ''starts'' the test suite. Note: It must not ''contain'' the test suite, only start it!

The test can be anything, from a simple shell script running a binary and checking its output to an elaborate system of test binaries and data files.

One major point of ptest is to consolidate the output format of all tests into a single common format. The format selected is the automake "simple test" format:

result: testname

Where "result" is one of PASS, FAIL or SKIP and "testname" can be any identifying string. (The same format [http://www.gnu.org/software/automake/manual/automake.html#Simple-Tests used by Automake].)

==General recipe preparations==

First, add "ptest" to the "inherit" line in the package recipe.

If a test adds build-time or run-time dependencies to the package which are not there normally (such as requiring "make" to run the test suite), add those with a -ptest suffix, like this:

RDEPENDS_${PN}-ptest += "make"

==Building the test suite==

Few packages support cross-compiling their test suites, so this is something we typically have to add.

Many automake-based packages compile and run the test suite in a single command: "make check". This doesn't work when cross-compiling, since we need to build on host and run on target. So we need to split that into two targets: One for building the test and one for running it. Our build of automake comes with a [http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/automake/automake/buildtest.patch patch] which does this automatically, so packages using the plain "make check" arrangement from automake get this automatically.

Now add a do_compile_ptest function to build the test suite:

do_compile_ptest() {
oe_runmake buildtest-TESTS
}

If the package requires special configuration actions prior to compiling the test code, create a do_configure_ptest function to do that.

==Installing the test suite==

The ptest.bbclass will automatically copy the required "run-ptest" file and run "make install-ptest" if there is such a target in the top-level Makefile. For packages where this is enough, you don't need to do anything else.

If you need to do something more than the automatic "make install-ptest", create a do_install_ptest function and put the required actions there. This function will be called after "make install-ptest" has completed.

Ptest

2013-03-08T12:47:29Z

BjornStenberg: /* Installing the test suite */

=Introduction=

Ptest (''package test'') is a concept for building, installing and running the test suites that are included in many packages, and producing a consistent output format.

=Adding ptest to your build=

Ptest is enabled in your build by adding "ptest" to the DISTRO_FEATURES variable and "ptest-pkgs" to the IMAGE_FEATURES variable in your image (or EXTRA_IMAGE_FEATURES in your local.conf). This will cause ptest-enabled packages to build and install the test suite in /usr/lib/<package>/ptest.

=Running ptest=

The "ptest-runner" package installs a "ptest-runner" shell script which loops through all installed ptest test suites and runs them in sequence.

=Adding ptest support to a package=

==What constitutes a ptest?==

A ptest must at minimum contain two things: run-ptest and the actual test.

run-ptest is a minimal shell script that ''starts'' the test suite. Note: It must not ''contain'' the test suite, only start it!

The test can be anything, from a simple shell script running a binary and checking its output to an elaborate system of test binaries and data files.

One major point of ptest is to consolidate the output format of all tests into a single common format. The format selected is the automake "simple test" format:

result: testname

Where "result" is one of PASS, FAIL or SKIP and "testname" can be any identifying string. (The same format [http://www.gnu.org/software/automake/manual/automake.html#Simple-Tests used by Automake].)

==General recipe preparations==

First, add "ptest" to the "inherit" line in the package recipe.

If a test adds build-time or run-time dependencies to the package which are not there normally (such as requiring "make" to run the test suite), add those with a -ptest suffix, like this:

RDEPENDS_${PN}-ptest += "make"

==Building the test suite==

Few packages support cross-compiling their test suites, so this is something we typically have to add.

Many automake-based packages compile and run the test suite in a single command: "make check". This doesn't work when cross-compiling, since we need to build on host and run on target. So we need to split that into two targets: One for building the test and one for running it. Our build of automake comes with a patch which does this automatically, so packages using the plain "make check" arrangement from automake get this automatically.

Now add a do_compile_ptest function to build the test suite:

do_compile_ptest() {
oe_runmake buildtest-TESTS
}

If the package requires special configuration actions prior to compiling the test code, create a do_configure_ptest function to do that.

==Installing the test suite==

The ptest.bbclass will automatically copy the required "run-ptest" file and run "make install-ptest" if there is such a target in the top-level Makefile. For packages where this is enough, you don't need to add any ptest install actions.

If you need to do anything more than "make install-ptest", create a do_install_ptest function and put the required actions there. This function will be called after "make install-ptest" has completed.

Ptest

2013-03-08T12:46:55Z

BjornStenberg: Updated for new _ptest functions.

=Introduction=

Ptest (''package test'') is a concept for building, installing and running the test suites that are included in many packages, and producing a consistent output format.

=Adding ptest to your build=

Ptest is enabled in your build by adding "ptest" to the DISTRO_FEATURES variable and "ptest-pkgs" to the IMAGE_FEATURES variable in your image (or EXTRA_IMAGE_FEATURES in your local.conf). This will cause ptest-enabled packages to build and install the test suite in /usr/lib/<package>/ptest.

=Running ptest=

The "ptest-runner" package installs a "ptest-runner" shell script which loops through all installed ptest test suites and runs them in sequence.

=Adding ptest support to a package=

==What constitutes a ptest?==

A ptest must at minimum contain two things: run-ptest and the actual test.

run-ptest is a minimal shell script that ''starts'' the test suite. Note: It must not ''contain'' the test suite, only start it!

The test can be anything, from a simple shell script running a binary and checking its output to an elaborate system of test binaries and data files.

One major point of ptest is to consolidate the output format of all tests into a single common format. The format selected is the automake "simple test" format:

result: testname

Where "result" is one of PASS, FAIL or SKIP and "testname" can be any identifying string. (The same format [http://www.gnu.org/software/automake/manual/automake.html#Simple-Tests used by Automake].)

==General recipe preparations==

First, add "ptest" to the "inherit" line in the package recipe.

If a test adds build-time or run-time dependencies to the package which are not there normally (such as requiring "make" to run the test suite), add those with a -ptest suffix, like this:

RDEPENDS_${PN}-ptest += "make"

==Building the test suite==

Few packages support cross-compiling their test suites, so this is something we typically have to add.

Many automake-based packages compile and run the test suite in a single command: "make check". This doesn't work when cross-compiling, since we need to build on host and run on target. So we need to split that into two targets: One for building the test and one for running it. Our build of automake comes with a patch which does this automatically, so packages using the plain "make check" arrangement from automake get this automatically.

Now add a do_compile_ptest function to build the test suite:

do_compile_ptest() {
oe_runmake buildtest-TESTS
}

If the package requires special configuration actions prior to compiling the test code, create a do_configure_ptest function to do that.

==Installing the test suite==

The ptest.bbclass will automatically copy the required "run-ptest" file and run "make install-ptest" if there is such a target in the top-level Makefile. For packages where this is enough, you don't need to add any ptest install code.

If you need to do anything more than "make install-ptest", create a do_install_ptest function and put the required actions there. This function will be called after "make install-ptest" has completed.

Ptest

2013-02-08T15:01:25Z

BjornStenberg:

=Introduction=

Ptest (''package test'') is a concept for building, installing and running the test suites that are included in many packages, and producing a consistent output format.

=Adding ptest to your build=

Ptest is enabled in your build by adding "ptest" to the DISTRO_FEATURES variable and "ptest-pkgs" to the IMAGE_FEATURES variable in your image (or EXTRA_IMAGE_FEATURES in your local.conf). This will cause ptest-enabled packages to build and install the test suite in /usr/lib/<package>/ptest.

=Running ptest=

The "ptest-runner" package installs a "ptest-runner" shell script which loops through all installed ptest test suites and runs them in sequence.

=Adding ptest support to a package=

==What constitutes a ptest?==

A ptest must at minimum contain two things: run-ptest and the actual test.

run-ptest is a minimal shell script that ''starts'' the test suite. Note: It must not ''contain'' the test suite, only start it!

The test can be anything, from a simple shell script running a binary and checking its output to an elaborate system of test binaries and data files.

One major point of ptest is to consolidate the output format of all tests into a single common format. The format selected is the automake "simple test" format:

result: testname

Where "result" is one of PASS, FAIL or SKIP and "testname" can be any identifying string. (The same format [http://www.gnu.org/software/automake/manual/automake.html#Simple-Tests used by Automake].)

==General recipe preparations==

First, add "ptest" to the "inherit" line in the package recipe.

If a test adds build-time or run-time dependencies to the package which are not there normally (such as requiring "make" to run the test suite), add those with a -ptest suffix, like this:

RDEPENDS_${PN}-ptest += "make"

==Building the test suite==

Few packages support cross-compiling their test suites, so this is something we typically have to add.

Many automake-based packages compile and run the test suite in a single command: "make check". This doesn't work when cross-compiling (since we need to build on host and run on target), so we need to split that into two targets: One for building the test and one for running it. Our build of automake comes with a patch which does this, so packages using the plain "make check" arrangement from automake get this automatically.

Now add a do_compile_append function to build the test suite:

do_compile_append() {
if [ "${PN}" = "${BPN}" -a ${PTEST_ENABLED} = "1" ]; then
oe_runmake buildtest-TESTS
fi
}

==Installing the test suite==

The ptest.bbclass contains a ptest_do_install function which copies the required "run-ptest" file and runs "make install-ptest" if there is such a target in the top-level Makefile. This provides a standardized install method to use in the package do_install_append function:

do_install_append() {
ptest_do_install
}

Ptest

2013-02-08T15:00:58Z

BjornStenberg:

=Introduction=

Ptest (''package test'') is a concept for building, installing and running the test suites that are included in many packages, and producing a consistent output format.

=Adding ptest to your build=

Ptest is enabled in your build by adding "ptest" to the DISTRO_FEATURES variable and "ptest-pkgs" to IMAGE_FEATURES of your image (or EXTRA_IMAGE_FEATURES in your local.conf). This will cause ptest-enabled packages to build and install the test suite in /usr/lib/<package>/ptest.

=Running ptest=

The "ptest-runner" package installs a "ptest-runner" shell script which loops through all installed ptest test suites and runs them in sequence.

=Adding ptest support to a package=

==What constitutes a ptest?==

A ptest must at minimum contain two things: run-ptest and the actual test.

run-ptest is a minimal shell script that ''starts'' the test suite. Note: It must not ''contain'' the test suite, only start it!

The test can be anything, from a simple shell script running a binary and checking its output to an elaborate system of test binaries and data files.

One major point of ptest is to consolidate the output format of all tests into a single common format. The format selected is the automake "simple test" format:

result: testname

Where "result" is one of PASS, FAIL or SKIP and "testname" can be any identifying string. (The same format [http://www.gnu.org/software/automake/manual/automake.html#Simple-Tests used by Automake].)

==General recipe preparations==

First, add "ptest" to the "inherit" line in the package recipe.

If a test adds build-time or run-time dependencies to the package which are not there normally (such as requiring "make" to run the test suite), add those with a -ptest suffix, like this:

RDEPENDS_${PN}-ptest += "make"

==Building the test suite==

Few packages support cross-compiling their test suites, so this is something we typically have to add.

Many automake-based packages compile and run the test suite in a single command: "make check". This doesn't work when cross-compiling (since we need to build on host and run on target), so we need to split that into two targets: One for building the test and one for running it. Our build of automake comes with a patch which does this, so packages using the plain "make check" arrangement from automake get this automatically.

Now add a do_compile_append function to build the test suite:

do_compile_append() {
if [ "${PN}" = "${BPN}" -a ${PTEST_ENABLED} = "1" ]; then
oe_runmake buildtest-TESTS
fi
}

==Installing the test suite==

The ptest.bbclass contains a ptest_do_install function which copies the required "run-ptest" file and runs "make install-ptest" if there is such a target in the top-level Makefile. This provides a standardized install method to use in the package do_install_append function:

do_install_append() {
ptest_do_install
}

Ptest

2013-02-08T15:00:36Z

BjornStenberg:

=Introduction=

Ptest (''package test'') is a concept for building, installing and running the test suites that are included in many packages, and producing a consistent output format.

=Adding ptest to your build=

Ptest is enabled in your build by adding "ptest" to the DISTRO_FEATURES variable and "ptest-pkgs" to IMAGE_FEATURES of your image, or EXTRA_IMAGE_FEATURES in your local.conf. This will cause ptest-enabled packages to build and install the test suite in /usr/lib/<package>/ptest.

=Running ptest=

The "ptest-runner" package installs a "ptest-runner" shell script which loops through all installed ptest test suites and runs them in sequence.

=Adding ptest support to a package=

==What constitutes a ptest?==

A ptest must at minimum contain two things: run-ptest and the actual test.

run-ptest is a minimal shell script that ''starts'' the test suite. Note: It must not ''contain'' the test suite, only start it!

The test can be anything, from a simple shell script running a binary and checking its output to an elaborate system of test binaries and data files.

One major point of ptest is to consolidate the output format of all tests into a single common format. The format selected is the automake "simple test" format:

result: testname

Where "result" is one of PASS, FAIL or SKIP and "testname" can be any identifying string. (The same format [http://www.gnu.org/software/automake/manual/automake.html#Simple-Tests used by Automake].)

==General recipe preparations==

First, add "ptest" to the "inherit" line in the package recipe.

If a test adds build-time or run-time dependencies to the package which are not there normally (such as requiring "make" to run the test suite), add those with a -ptest suffix, like this:

RDEPENDS_${PN}-ptest += "make"

==Building the test suite==

Few packages support cross-compiling their test suites, so this is something we typically have to add.

Many automake-based packages compile and run the test suite in a single command: "make check". This doesn't work when cross-compiling (since we need to build on host and run on target), so we need to split that into two targets: One for building the test and one for running it. Our build of automake comes with a patch which does this, so packages using the plain "make check" arrangement from automake get this automatically.

Now add a do_compile_append function to build the test suite:

do_compile_append() {
if [ "${PN}" = "${BPN}" -a ${PTEST_ENABLED} = "1" ]; then
oe_runmake buildtest-TESTS
fi
}

==Installing the test suite==

The ptest.bbclass contains a ptest_do_install function which copies the required "run-ptest" file and runs "make install-ptest" if there is such a target in the top-level Makefile. This provides a standardized install method to use in the package do_install_append function:

do_install_append() {
ptest_do_install
}

Ptest

2013-01-17T09:12:37Z

BjornStenberg:

=Introduction=

Ptest (''package test'') is a concept for building, installing and running the test suites that are included in many packages, and producing a consistent output format.

=Adding ptest to your build=

Ptest is enabled in your build by adding "ptest" to the DISTRO_FEATURES variable. This will cause ptest-enabled packages to build and install the test suite in /usr/lib/<package>/ptest.

=Running ptest=

The "ptest-runner" package installs a "ptest-runner" shell script which loops through all installed ptest test suites and runs them in sequence.

=Adding ptest support to a package=

==What constitutes a ptest?==

A ptest must at minimum contain two things: run-ptest and the actual test.

run-ptest is a minimal shell script that ''starts'' the test suite. Note: It must not ''contain'' the test suite, only start it!

The test can be anything, from a simple shell script running a binary and checking its output to an elaborate system of test binaries and data files.

One major point of ptest is to consolidate the output format of all tests into a single common format. The format selected is the automake "simple test" format:

result: testname

Where "result" is one of PASS, FAIL or SKIP and "testname" can be any identifying string. (The same format [http://www.gnu.org/software/automake/manual/automake.html#Simple-Tests used by Automake].)

==General recipe preparations==

First, add "ptest" to the "inherit" line in the package recipe.

If a test adds build-time or run-time dependencies to the package which are not there normally (such as requiring "make" to run the test suite), add those with a -ptest suffix, like this:

RDEPENDS_${PN}-ptest += "make"

==Building the test suite==

Few packages support cross-compiling their test suites, so this is something we typically have to add.

Many automake-based packages compile and run the test suite in a single command: "make check". This doesn't work when cross-compiling (since we need to build on host and run on target), so we need to split that into two targets: One for building the test and one for running it. Our build of automake comes with a patch which does this, so packages using the plain "make check" arrangement from automake get this automatically.

Now add a do_compile_append function to build the test suite:

do_compile_append() {
if [ "${PN}" = "${BPN}" -a ${PTEST_ENABLED} = "1" ]; then
oe_runmake buildtest-TESTS
fi
}

==Installing the test suite==

The ptest.bbclass contains a ptest_do_install function which copies the required "run-ptest" file and runs "make install-ptest" if there is such a target in the top-level Makefile. This provides a standardized install method to use in the package do_install_append function:

do_install_append() {
ptest_do_install
}

Ptest

2013-01-16T15:12:17Z

BjornStenberg:

=Introduction=

Ptest (''package test'') is a concept for building, installing and running the test suites that are included in many packages, and producing a consistent output format.

=Adding ptest to your build=

Ptest is enabled in your build by adding "ptest" to the DISTRO_FEATURES variable. This will cause ptest-enabled packages to build and install the test suite in /usr/lib/<package>/ptest.

=Running ptest=

The "ptest-runner" package installs a "ptest-runner" shell script which loops through all installed ptest test suites and runs them in sequence.

=Adding ptest support to a package=

==What constitutes a ptest?==

A ptest must at minimum contain two things: run-ptest and the actual test.

run-ptest is a minimal shell script that ''starts'' the test suite. Note: It must not ''contain'' the test suite, only start it!

The test can be anything, from a simple shell script running a binary and checking its output to an elaborate system of test binaries and data files.

One major point of ptest is to consolidate the output format of all tests into a single common format. The format selected is the automake "simple test" format:

result: testname

Where "result" is one of PASS, FAIL or SKIP and "testname" can be any identifying string. (The same format [http://www.gnu.org/software/automake/manual/automake.html#Simple-Tests used by Automake].)

==General recipe preparations==

First, add "ptest" to the "inherit" line in the package recipe.

If a test adds build-time or run-time dependencies to the package which are not there normally (such as requiring "make" to run the test suite), add those with a -ptest suffix, like this:

RDEPENDS_${PN}-ptest += "make"

==Building the test suite==

Few packages support cross-compiling their test suites, so this is something we typically have to add.

Many automake-based packages compile and run the test suite in a single command: "make check". This doesn't work when cross-compiling (since we need to build on host and run on target), so we need to split that into two targets: One for building the test and one for running it. Our build of automake comes with a patch which does this, so packages using the plain "make check" arrangement from automake get this automatically.

Now add a do_compile_append function to build the test suite:

do_compile_append() {
if [ "${PN}" = "${BPN}" -a ${PTEST_ENABLED} = "1" ]; then
oe_runmake buildtest-TESTS
fi
}

==Installing the test suite==

The ptest.bbclass contains a ptest_do_install function which copies the required "run-ptest" file and runs "make install-ptest" if there is such a target in the top-level Makefile. This provides a standardized install method to use in the package do_install_append function:

do_compile_append() {
ptest_do_install
}

Ptest

2013-01-16T08:30:46Z

BjornStenberg:

=Introduction=

Ptest (''package test'') is a concept for building, installing and running the test suites that are included in many packages, and producing a consistent output format.

=Adding ptest to your build=

Ptest is enabled in your build by adding "ptest" to the DISTRO_FEATURES variable. This will cause ptest-enabled packages to build and install the test suite in /usr/lib/<package>/ptest.

=Running ptest=

The "ptest-runner" package installs a "ptest-runner" shell script which loops through all installed ptest test suites and runs them in sequence.

=Adding ptest support to a package=

==What constitutes a ptest?==

A ptest must at minimum contain two things: run-ptest and the actual test.

run-ptest is a minimal shell script that ''starts'' the test suite. Note: It must not ''contain'' the test suite, only start it!

The test can be anything, from a simple shell script running a binary and checking its output to an elaborate system of test binaries and data files.

One major point of ptest is to consolidate the output format of all tests into a single common format. The format selected is the automake "simple test" format:

result: testname

Where "result" is one of PASS, FAIL or SKIP and "testname" can be any identifying string. (The the same format used by Automake: http://www.gnu.org/software/automake/manual/automake.html#Simple-Tests)

==General recipe preparations==

First, add "ptest" to the "inherit" line in the package recipe.

If a test adds build-time or run-time dependencies to the package which are not there normally (such as requiring "make" to run the test suite), add those with a -ptest suffix, like this:

RDEPENDS_${PN}-ptest += "make"

==Building the test suite==

Few packages support cross-compiling their test suites, so this is something we typically have to add.

Many automake-based packages compile and run the test suite in a single command: "make check". This doesn't work when cross-compiling (since we need to build on host and run on target), so we need to split that into two targets: One for building the test and one for running it. Our build of automake comes with a patch which does this, so packages using the plain "make check" arrangement from automake get this automatically.

Now add a do_compile_append function to build the test suite:

do_compile_append() {
if [ "${PN}" = "${BPN}" -a ${PTEST_ENABLED} = "1" ]; then
oe_runmake buildtest-TESTS
fi
}

==Installing the test suite==

The ptest.bbclass contains a ptest_do_install function which copies the required "run-ptest" file and runs "make install-ptest" if there is such a target in the top-level Makefile. This provides a standardized install method to use in the package do_install_append function:

do_compile_append() {
ptest_do_install
}

Ptest

2013-01-08T14:56:57Z

BjornStenberg:

=Introduction=

Ptest (''package test'') is a concept for building, installing and running the test suites that are included in many packages, and producing a consistent output format.

=Adding ptest to your build=

Ptest is enabled in your build by adding "ptest" to the DISTRO_FEATURES variable. This will cause ptest-enabled packages to build and install the test suite in /usr/lib/<package>/ptest.

=Running ptest=

The "ptest-runner" package installs a "ptest-runner" shell script which loops through all installed ptest test suites and runs them in sequence.

=Adding ptest support to a package=

==What constitutes a ptest?==

A ptest must at minimum contain two things: run-ptest and the actual test.

run-ptest is a minimal shell script that ''starts'' the test suite. Note: It must not ''contain'' the test suite, only start it!

The test can be anything, from a simple shell script running a binary and checking its output to an elaborate system of test binaries and data files.

One major point of ptest is to consolitate the output format of all tests into a single common format. The format selected is the automake "simple test" format:

result: testname

Where "result" one of PASS, FAIL or SKIP and "testname" can be any identifying string.

==General recipe preparations==

First, add "ptest" to the "inherit" line in the package recipe.

If a test adds build-time or run-time dependencies to the package which are not there normally (such as requiring "make" to run the test suite), add those with a -ptest prefix, like this:

RDEPENDS_${PN}-ptest += "make"

==Building the test suite==

Few packages support cross-compiling their test suites, so this is something we typically have to add.

Many automake-based packages compile and run the test suite in a single command: "make check". This doesn't work when cross-compiling (since we need to build on host and run on target), so we need to split that into two targets: One for building the test and one for running it. Our build of automake comes with a patch which does this, so packages using the plain "make check" arrangement from automake get this automatically.

Now add a do_compile_append function to build the test suite:

do_compile_append() {
if [ "${PN}" = "${BPN}" -a ${PTEST_ENABLED} = "1" ]; then
oe_runmake buildtest-TESTS
fi
}

==Installing the test suite==

The ptest.bbclass contains a ptest_do_install function which copies the required "run-ptest" file and runs "make install-ptest" if there is such a target in the top-level Makefile. This provides a standardized install method to use in the package do_install_append function:

do_compile_append() {
ptest_do_install
}

Ptest

2013-01-08T14:52:40Z

BjornStenberg:

=Introduction=

Ptest (''package test'') is a concept for building, installing and running the test suites that are included in many packages.

=Adding ptest to your build=

Ptest is enabled in your build by adding "ptest" to the DISTRO_FEATURES variable. This will cause ptest-enabled packages to build and install the test suite in /usr/lib/<package>/ptest.

=Running ptest=

The "ptest-runner" package installs a "ptest-runner" shell script which loops through all installed ptest test suites and runs them in sequence.

=Adding ptest support to a package=

==What constitutes a ptest?==

A ptest must at minimum contain two things: run-ptest and the actual test.

run-ptest is a minimal shell script that ''starts'' the test suite. Note: It must not ''contain'' the test suite, only start it!

==General recipe preparations==

First, add "ptest" to the "inherit" line in the package recipe.

If a test adds build-time or run-time dependencies to the package which are not there normally (such as requiring "make" to run the test suite), add those with a -ptest prefix, like this:

RDEPENDS_${PN}-ptest += "make"

==Building the test suite==

Few packages support cross-compiling their test suites, so this is something we typically have to add.

Many automake-based packages compile and run the test suite in a single command: "make check". This doesn't work when cross-compiling (since we need to build on host and run on target), so we need to split that into two targets: One for building the test and one for running it. Our build of automake comes with a patch which does this, so packages using the plain "make check" arrangement from automake get this automatically.

Now add a do_compile_append function to build the test suite:

do_compile_append() {
if [ "${PN}" = "${BPN}" -a ${PTEST_ENABLED} = "1" ]; then
oe_runmake buildtest-TESTS
fi
}

==Installing the test suite==

The ptest.bbclass contains a ptest_do_install function which copies the required "run-ptest" file and runs "make install-ptest" if there is such a target in the top-level Makefile. This provides a standardized install method to use in the package do_install_append function:

do_compile_append() {
ptest_do_install
}

Ptest

2013-01-08T14:50:19Z

BjornStenberg:

==Introduction==

Ptest (''package test'') is a concept for building, installing and running the test suites that are included in many packages.

==Adding ptest to your build==

Ptest is enabled in your build by adding "ptest" to the DISTRO_FEATURES variable. This will cause ptest-enabled packages to build and install the test suite in /usr/lib/<package>/ptest.

==Running ptest==

The "ptest-runner" package installs a "ptest-runner" shell script which loops through all installed ptest test suites and runs them in sequence.

==Adding ptest support to a package==

=What constitutes a ptest?=

A ptest must at minimum contain two things: run-ptest and the actual test.

run-ptest is a minimal shell script that ''starts'' the test suite. Note: It must not ''contain'' the test suite, only start it!

The

=General recipe preparations=

First, add "ptest" to the "inherit" line in the package recipe.

If a test adds build-time or run-time dependencies to the package which are not there normally (such as requiring "make" to run the test suite), add those with a -ptest prefix, like this:

RDEPENDS_${PN}-ptest += "make"

=Building the test suite=

Very few packages support cross-compiling their test suites, so this is something we typically need to add.

Many automake-based packages compile and run the test suite in a single command: make check. This doesn't work when cross-compiling, so we need to split that into two targets: One for building the test and one for running it. We include a patch in our build of automake which does this, so packages using the plain "make check" arrangement from automake get this automatically.

Now add a do_compile_append function to build the test suite:

do_compile_append() {
if [ "${PN}" = "${BPN}" -a ${PTEST_ENABLED} = "1" ]; then
oe_runmake buildtest-TESTS
fi
}

=Installing the test suite=

The ptest.bbclass contains a ptest_do_install function which copies the required "run-ptest" file and runs "make install-ptest" if there is such a target in the top-level Makefile. This provides a standardized install method to use in the package do_install or do_install_append.

Ptest

2013-01-08T13:39:40Z

BjornStenberg: Created page with "=Introduction= Ptest (''package test'') is a concept for building, installing and running the test suites that are included in many packages. =Adding ptest to your build= Ptes..."

Build Performance

2012-04-19T07:26:47Z

BjornStenberg:

This page is intended to serve as a guide to tweaking your build system and bitbake configuration for optimal build time as well as to provide some guidance on how to collect build metrics and identify bottlenecks.

== General Tips ==

Some general tips on how to ensure good performance of builds:

* Put the build directory on its own disk. This is good practice in its own right since the build system has a tendency to wear disks heavily.
* Use the ext4 filesystem for the build disk
* Turn off journaling for ext4 ("tune2fs -O ^has_journal <disk>")
* Mount using the options "noatime,barrier=0,commit=6000"
* Use a tmpfs for /tmp

== bb-matrix ==
The bb-matrix.sh script (scripts/contrib/bb-perf) can be used to collect all the relevant metrics of the TIME(1) command for a build. The bb-matrix.sh generates a datfile similar to the following (trimmed for display purposes):

BB PM %e %S %U %P %c %w %R %F %M
04 04 7584.13 3106.60 19818.78 302% 10038479 53837200 2381052920 52972 1857632
04 05 7488.93 3143.40 20344.21 313% 10290920 53308215 2380549395 51668 2027232
04 06 7524.69 3141.34 20575.58 315% 10287288 53626500 2380333579 51820 2027248
04 07 7464.62 3141.47 20741.94 319% 10613016 53459858 2381025909 50929 2027376
04 08 7570.45 3151.23 20949.85 318% 10625744 53485726 2382061127 52367 2027232
05 04 7479.95 3254.95 20444.40 316% 13858856 50054205 2387500546 53457 2027232
05 05 7494.82 3282.37 20643.16 319% 14274000 49852477 2380346993 52289 2027248
05 06 7432.55 3277.54 21049.68 327% 14340685 49998524 2380221845 53622 2027376
05 07 7377.66 3300.18 21238.96 332% 13926958 50634688 2384699997 53851 1941840
05 08 7408.57 3297.64 21306.12 332% 14139864 50330053 2380869210 54169 1912272

The bb-matrix-plot.sh script can then be used to visualize this data, generating images like the following:

[[File:Bb-matrix-f3.png]]

== buildstats ==
If you enable buildstats (by adding <tt>INHERIT += "buildstats"</tt> to local.conf) you will get detailed build performance log data in tmp/buildstats.

Richard Purdie has [https://lists.yoctoproject.org/pipermail/poky/2011-February/003740.html modified pybootbootchartgui] to parse this data and produce [http://tim.rpsys.net/bootchart.png pretty charts].

== parallelism ==
Small builds do not scale to a large number of cores, due to package inter-dependencies. Going far beyond 8 is not giving much benefit. Here is a graph of a 64-core machine building core-image-minimal with different build parameters:

[[File:Bb-matrix-f3-64.png]]

Bigger builds are less hampered by linear dependency chains, and fill the cores better.

== discussion ==
Build system performance is a recurring mailing list topic. [http://lists.linuxtogo.org/pipermail/openembedded-core/2011-September/010179.html Here] is Richard Purdie discussing the challenges of improving many-core build performance and package dependency issues.

Build Performance

2012-04-16T13:09:37Z

BjornStenberg:

This page is intended to serve as a guide to tweaking your build system and bitbake configuration for optimal build time as well as to provide some guidance on how to collect build metrics and identify bottlenecks.

== General Tips ==

Some general tips on how to ensure good performance of builds:

* Put the build directory on its own disk. This is good practice in its own right since the build system has a tendency to wear disks heavily.
* Use the ext4 filesystem for the build disk
* Turn off journaling for ext4 ("tune2fs -O ^has_journal <disk>")
* Mount using the options "noatime,barrier=0,commit=6000"
* Use a tmpfs for /tmp

== bb-matrix ==
The bb-matrix.sh script (scripts/contrib/bb-perf) can be used to collect all the relevant metrics of the TIME(1) command for a build. The bb-matrix.sh generates a datfile similar to the following (trimmed for display purposes):

BB PM %e %S %U %P %c %w %R %F %M
04 04 7584.13 3106.60 19818.78 302% 10038479 53837200 2381052920 52972 1857632
04 05 7488.93 3143.40 20344.21 313% 10290920 53308215 2380549395 51668 2027232
04 06 7524.69 3141.34 20575.58 315% 10287288 53626500 2380333579 51820 2027248
04 07 7464.62 3141.47 20741.94 319% 10613016 53459858 2381025909 50929 2027376
04 08 7570.45 3151.23 20949.85 318% 10625744 53485726 2382061127 52367 2027232
05 04 7479.95 3254.95 20444.40 316% 13858856 50054205 2387500546 53457 2027232
05 05 7494.82 3282.37 20643.16 319% 14274000 49852477 2380346993 52289 2027248
05 06 7432.55 3277.54 21049.68 327% 14340685 49998524 2380221845 53622 2027376
05 07 7377.66 3300.18 21238.96 332% 13926958 50634688 2384699997 53851 1941840
05 08 7408.57 3297.64 21306.12 332% 14139864 50330053 2380869210 54169 1912272

The bb-matrix-plot.sh script can then be used to visualize this data, generating images like the following:

[[File:Bb-matrix-f3.png]]

== buildstats ==
If you enable buildstats (by adding <tt>INHERIT += "buildstats"</tt> to local.conf) you will get detailed build performance log data in tmp/buildstats.

Richard Purdie has [https://lists.yoctoproject.org/pipermail/poky/2011-February/003740.html modified pybootbootchartgui] to parse this data and produce pretty charts like above.

== parallelism ==
Small builds do not scale to a large number of cores, due to package inter-dependencies. Going far beyond 8 is not giving much benefit. Here is a graph of a 64-core machine building core-image-minimal with different build parameters:

[[File:Bb-matrix-f3-64.png]]

Bigger builds are less hampered by linear dependency chains, and fill the cores better.

== discussion ==
Build system performance is a recurring mailing list topic. [http://lists.linuxtogo.org/pipermail/openembedded-core/2011-September/010179.html Here] is Richard Purdie discussing the challenges of improving many-core build performance and package dependency issues.

Build Performance

2012-04-16T13:03:22Z

BjornStenberg:

This page is intended to serve as a guide to tweaking your build system and bitbake configuration for optimal build time as well as to provide some guidance on how to collect build metrics and identify bottlenecks.

== General Tips ==

Some general tips on how to ensure good performance of builds:

* Put the build directory on its own disk. This is good practice in its own right since the build system has a tendency to wear disks heavily.
* Use the ext4 filesystem for the build disk
* Turn off journaling for ext4 ("tune2fs -O ^has_journal <disk>")
* Mount using the options "noatime,barrier=0,commit=6000"
* Use a tmpfs for /tmp

== bb-matrix ==
The bb-matrix.sh script (scripts/contrib/bb-perf) can be used to collect all the relevant metrics of the TIME(1) command for a build. The bb-matrix.sh generates a datfile similar to the following (trimmed for display purposes):

BB PM %e %S %U %P %c %w %R %F %M
04 04 7584.13 3106.60 19818.78 302% 10038479 53837200 2381052920 52972 1857632
04 05 7488.93 3143.40 20344.21 313% 10290920 53308215 2380549395 51668 2027232
04 06 7524.69 3141.34 20575.58 315% 10287288 53626500 2380333579 51820 2027248
04 07 7464.62 3141.47 20741.94 319% 10613016 53459858 2381025909 50929 2027376
04 08 7570.45 3151.23 20949.85 318% 10625744 53485726 2382061127 52367 2027232
05 04 7479.95 3254.95 20444.40 316% 13858856 50054205 2387500546 53457 2027232
05 05 7494.82 3282.37 20643.16 319% 14274000 49852477 2380346993 52289 2027248
05 06 7432.55 3277.54 21049.68 327% 14340685 49998524 2380221845 53622 2027376
05 07 7377.66 3300.18 21238.96 332% 13926958 50634688 2384699997 53851 1941840
05 08 7408.57 3297.64 21306.12 332% 14139864 50330053 2380869210 54169 1912272

The bb-matrix-plot.sh script can then be used to visualize this data, generating images like the following:

[[File:Bb-matrix-f3.png]]

== buildstats ==
If you enable buildstats (by adding <tt>INHERIT += "buildstats"</tt> to local.conf) you will get detailed build performance log data in tmp/buildstats.

Richard Purdie has [https://lists.yoctoproject.org/pipermail/poky/2011-February/003740.html modified pybootbootchartgui] to parse this data and produce pretty charts like above.

== parallelism ==
Small builds do not scale to a large number of cores, due to package inter-dependencies. Going far beyond 8 is not giving much benefit. See this graph of different build parameters on a 64-core machine when building core-image-minimal:

[[File:Bb-matrix-f3-64.png]]

Bigger builds are less hampered by linear dependency chains, and fill the cores better.

== discussion ==
Build system performance is a recurring mailing list topic. [http://lists.linuxtogo.org/pipermail/openembedded-core/2011-September/010179.html Here] is Richard Purdie discussing the challenges of improving many-core build performance and package dependency issues.

Build Performance

2012-04-16T13:01:45Z

BjornStenberg:

This page is intended to serve as a guide to tweaking your build system and bitbake configuration for optimal build time as well as to provide some guidance on how to collect build metrics and identify bottlenecks.

== General Tips ==

Some general tips on how to ensure good performance of builds:

* Put the build directory on its own disk. This is good practice in its own right since the build system has a tendency to wear disks heavily.
* Use the ext4 filesystem for the build disk
* Turn off journaling for ext4 ("tune2fs -O ^has_journal <disk>")
* Mount using the options "noatime,barrier=0,commit=6000"
* Use a tmpfs for /tmp

== bb-matrix ==
The bb-matrix.sh script (scripts/contrib/bb-perf) can be used to collect all the relevant metrics of the TIME(1) command for a build. The bb-matrix.sh generates a datfile similar to the following (trimmed for display purposes):

BB PM %e %S %U %P %c %w %R %F %M
04 04 7584.13 3106.60 19818.78 302% 10038479 53837200 2381052920 52972 1857632
04 05 7488.93 3143.40 20344.21 313% 10290920 53308215 2380549395 51668 2027232
04 06 7524.69 3141.34 20575.58 315% 10287288 53626500 2380333579 51820 2027248
04 07 7464.62 3141.47 20741.94 319% 10613016 53459858 2381025909 50929 2027376
04 08 7570.45 3151.23 20949.85 318% 10625744 53485726 2382061127 52367 2027232
05 04 7479.95 3254.95 20444.40 316% 13858856 50054205 2387500546 53457 2027232
05 05 7494.82 3282.37 20643.16 319% 14274000 49852477 2380346993 52289 2027248
05 06 7432.55 3277.54 21049.68 327% 14340685 49998524 2380221845 53622 2027376
05 07 7377.66 3300.18 21238.96 332% 13926958 50634688 2384699997 53851 1941840
05 08 7408.57 3297.64 21306.12 332% 14139864 50330053 2380869210 54169 1912272

The bb-matrix-plot.sh script can then be used to visualize this data, generating images like the following:

[[File:Bb-matrix-f3.png]]

== buildstats ==
If you enable buildstats (by adding <tt>INHERIT += "buildstats"</tt> to local.conf) you will get detailed build performance log data in tmp/buildstats.

Richard Purdie has [https://lists.yoctoproject.org/pipermail/poky/2011-February/003740.html modified pybootbootchartgui] to parse this data and produce pretty charts like above.

== parallelism ==
Small builds do not scale to a large number of cores, due to package inter-dependencies. Going far beyond 8 is not giving much benefit. See this graph of different build parameters on a 64-core machine when building core-image-minimal:

[[File:Bb-matrix-f3-64.png]]

== discussion ==
Build system performance is a recurring mailing list topic. [http://lists.linuxtogo.org/pipermail/openembedded-core/2011-September/010179.html Here] is Richard Purdie discussing the challenges of improving many-core build performance and package dependency issues.

Build Performance

2012-04-16T12:59:46Z

BjornStenberg:

This page is intended to serve as a guide to tweaking your build system and bitbake configuration for optimal build time as well as to provide some guidance on how to collect build metrics and identify bottlenecks.

== General Tips ==

Some general tips on how to ensure good performance of builds:

* Put the build directory on its own disk. This is good practice in its own right since the build system has a tendency to wear disks heavily.
* Use the ext4 filesystem for the build disk
* Turn off journaling for ext4 ("tune2fs -O ^has_journal <disk>")
* Mount using the options "noatime,barrier=0,commit=6000"
* Use a tmpfs for /tmp

== bb-matrix ==
The bb-matrix.sh script (scripts/contrib/bb-perf) can be used to collect all the relevant metrics of the TIME(1) command for a build. The bb-matrix.sh generates a datfile similar to the following (trimmed for display purposes):

BB PM %e %S %U %P %c %w %R %F %M
04 04 7584.13 3106.60 19818.78 302% 10038479 53837200 2381052920 52972 1857632
04 05 7488.93 3143.40 20344.21 313% 10290920 53308215 2380549395 51668 2027232
04 06 7524.69 3141.34 20575.58 315% 10287288 53626500 2380333579 51820 2027248
04 07 7464.62 3141.47 20741.94 319% 10613016 53459858 2381025909 50929 2027376
04 08 7570.45 3151.23 20949.85 318% 10625744 53485726 2382061127 52367 2027232
05 04 7479.95 3254.95 20444.40 316% 13858856 50054205 2387500546 53457 2027232
05 05 7494.82 3282.37 20643.16 319% 14274000 49852477 2380346993 52289 2027248
05 06 7432.55 3277.54 21049.68 327% 14340685 49998524 2380221845 53622 2027376
05 07 7377.66 3300.18 21238.96 332% 13926958 50634688 2384699997 53851 1941840
05 08 7408.57 3297.64 21306.12 332% 14139864 50330053 2380869210 54169 1912272

The bb-matrix-plot.sh script can then be used to visualize this data, generating images like the following:

[[File:Bb-matrix-f3.png]]

== buildstats ==
If you enable buildstats (by adding <tt>INHERIT += "buildstats"</tt> to local.conf) you will get detailed build performance log data in tmp/buildstats.

Richard Purdie has [https://lists.yoctoproject.org/pipermail/poky/2011-February/003740.html modified pybootbootchartgui] to parse this data and produce pretty charts like above.

== parallelism ==
The small builds does not scale to large number of cores, due to package inter-dependencies. Going far beyond 8 is not giving much benefit. See this graph showing the speed difference in using different build parameters on a 64-core machine when building core-image-minimal:

[[File:Bb-matrix-f3-64.png]]

== discussion ==
Build system performance is a recurring mailing list topic. [http://lists.linuxtogo.org/pipermail/openembedded-core/2011-September/010179.html Here] is Richard Purdie discussing the challenges of improving many-core build performance and package dependency issues.

File:Bb-matrix-f3-64.png

2012-04-16T12:55:48Z

BjornStenberg: Build parallelism benchmark on 64-core machine

Build parallelism benchmark on 64-core machine

Build Performance

2012-04-13T11:41:25Z

BjornStenberg:

This page is intended to serve as a guide to tweaking your build system and bitbake configuration for optimal build time as well as to provide some guidance on how to collect build metrics and identify bottlenecks.

== General Tips ==

Some general tips on how to ensure good performance of builds:

* Put the build directory on its own disk. This is good practice in its own right since the build system has a tendency to wear disks heavily.
* Use the ext4 filesystem for the build disk
* Turn off journaling for ext4 ("tune2fs -O ^has_journal <disk>")
* Mount using the options "noatime,barrier=0,commit=6000"
* Use a tmpfs for /tmp
* The build does not scale well to large number of cores, due to package inter-dependencies. Going much beyond 10-12 is not giving much benefit.

== bb-matrix ==
The bb-matrix.sh script (scripts/contrib/bb-perf) can be used to collect all the relevant metrics of the TIME(1) command for a build. The bb-matrix.sh generates a datfile similar to the following (trimmed for display purposes):

BB PM %e %S %U %P %c %w %R %F %M
04 04 7584.13 3106.60 19818.78 302% 10038479 53837200 2381052920 52972 1857632
04 05 7488.93 3143.40 20344.21 313% 10290920 53308215 2380549395 51668 2027232
04 06 7524.69 3141.34 20575.58 315% 10287288 53626500 2380333579 51820 2027248
04 07 7464.62 3141.47 20741.94 319% 10613016 53459858 2381025909 50929 2027376
04 08 7570.45 3151.23 20949.85 318% 10625744 53485726 2382061127 52367 2027232
05 04 7479.95 3254.95 20444.40 316% 13858856 50054205 2387500546 53457 2027232
05 05 7494.82 3282.37 20643.16 319% 14274000 49852477 2380346993 52289 2027248
05 06 7432.55 3277.54 21049.68 327% 14340685 49998524 2380221845 53622 2027376
05 07 7377.66 3300.18 21238.96 332% 13926958 50634688 2384699997 53851 1941840
05 08 7408.57 3297.64 21306.12 332% 14139864 50330053 2380869210 54169 1912272

The bb-matrix-plot.sh script can then be used to visualize this data, generating images like the following:

[[File:Bb-matrix-f3.png]]

== buildstats ==
If you enable buildstats (by adding <tt>INHERIT += "buildstats"</tt> to local.conf) you will get detailed build performance log data in tmp/buildstats.

Richard Purdie has [https://lists.yoctoproject.org/pipermail/poky/2011-February/003740.html modified pybootbootchartgui] to parse this data and produce a pretty chart. ([http://tim.rpsys.net/bootchart.png example])

== discussion ==
Build system performance is a recurring mailing list topic. [http://lists.linuxtogo.org/pipermail/openembedded-core/2011-September/010179.html Here] is Richard Purdie discussing the challenges of improving many-core build performance and package dependency issues.

Build Performance

2012-04-13T10:34:02Z

BjornStenberg:

This page is intended to serve as a guide to tweaking your build system and bitbake configuration for optimal build time as well as to provide some guidance on how to collect build metrics and identify bottlenecks.

== General Tips ==

Some general tips on how to ensure good performance of builds:

* Put the build directory on its own disk. This is good practice in its own right since the build system has a tendency to wear disks heavily.
* Use the ext4 filesystem for the build disk
* Turn off journaling for ext4 ("tune2fs -O ^has_journal <disk>")
* Mount using the options "noatime,barrier=0,commit=6000"
* Use a tmpfs for /tmp
* The build does not scale well to large number of cores, due to package inter-dependencies. Going much beyond 10-12 is not giving much benefit.

== bb-matrix ==
The bb-matrix.sh script (scripts/contrib/bb-perf) can be used to collect all the relevant metrics of the TIME(1) command for a build. The bb-matrix.sh generates a datfile similar to the following (trimmed for display purposes):

BB PM %e %S %U %P %c %w %R %F %M
04 04 7584.13 3106.60 19818.78 302% 10038479 53837200 2381052920 52972 1857632
04 05 7488.93 3143.40 20344.21 313% 10290920 53308215 2380549395 51668 2027232
04 06 7524.69 3141.34 20575.58 315% 10287288 53626500 2380333579 51820 2027248
04 07 7464.62 3141.47 20741.94 319% 10613016 53459858 2381025909 50929 2027376
04 08 7570.45 3151.23 20949.85 318% 10625744 53485726 2382061127 52367 2027232
05 04 7479.95 3254.95 20444.40 316% 13858856 50054205 2387500546 53457 2027232
05 05 7494.82 3282.37 20643.16 319% 14274000 49852477 2380346993 52289 2027248
05 06 7432.55 3277.54 21049.68 327% 14340685 49998524 2380221845 53622 2027376
05 07 7377.66 3300.18 21238.96 332% 13926958 50634688 2384699997 53851 1941840
05 08 7408.57 3297.64 21306.12 332% 14139864 50330053 2380869210 54169 1912272

The bb-matrix-plot.sh script can then be used to visualize this data, generating images like the following:

[[File:Bb-matrix-f3.png]]

== buildstats ==
If you enable buildstats (by adding <tt>INHERIT += "buildstats"</tt> to local.conf) you will get detailed build performance log data in tmp/buildstats.

Richard Purdie has [https://lists.yoctoproject.org/pipermail/poky/2011-February/003740.html modified bootchart] to produce pretty charts showing this data graphically. ([http://tim.rpsys.net/bootchart.png example])

== discussion ==
Build system performance is a recurring mailing list topic. [http://lists.linuxtogo.org/pipermail/openembedded-core/2011-September/010179.html Here] is Richard Purdie discussing the challenges of improving many-core build performance and package dependency issues.