[Buildroot] [PATCH 1/7 v4] docs/manual: document the test-pkg script

[Buildroot] [PATCH 1/7 v4] docs/manual: document the test-pkg script

[Yann E. MORIN]

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 docs/manual/adding-packages-tips.txt | 90 ++++++++++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)

diff --git a/docs/manual/adding-packages-tips.txt b/docs/manual/adding-packages-tips.txt
index 896be00..732904f 100644
--- a/docs/manual/adding-packages-tips.txt
+++ b/docs/manual/adding-packages-tips.txt
@@ -32,6 +32,96 @@ using the following rules:
   with `.` and `-` characters substituted with `_` (e.g.:
   +FOO_BAR_BOO_VERSION+).
 
+[[testing-package]]
+==== How to test your package
+
+Once you have added your new package, it is important that you test it
+under various conditions: does it build for all architectures? Does it
+build with the different C libraries? Does it need threads, NPTL? And
+so on...
+
+Buildroot runs http://autobuild.buildroot.org/[autobuilders] which
+continuously test random configurations. However, these only build the
+`master` branch of the git tree, and your new fancy package is not yet
+there.
+
+Buildroot provides a script in +support/scripts/test-pkg+ that uses the
+same base configurations as used by the autobuilders so you can test
+your package in the same conditions.
+
+First, create a config snippet that contains all the necessary options
+needed to enabel your package, but without any architecture or toolchain
+option. For example, let's create a config snippet that just enables
++libcurl+, without any TLS backend:
+
+----
+$ cat libcurl.config
+BR2_PACKAGE_LIBCURL=y
+----
+
+If your package needs more configuration options, you can add them to the
+config snippet. For example, here's how you would test +libcurl+ with
++openssl+ as a TLS backend and the +curl+ program:
+
+----
+$ cat libcurl.config
+BR2_PACKAGE_LIBCURL=y
+BR2_PACKAGE_CURL=y
+BR2_PACKAGE_OPENSSL=y
+----
+
+Then run the script, by telling it what config snippet to use and what
+package to test:
+
+----
+$ ./support/scripts/test-pkg -c libcurl.config -p libcurl
+----
+
+This will try to build your package against all the toolchains used
+by the autobuilders (but the internal toolchains, because it takes
+too long to do so). The output lists all toolchains and the corresponding
+result (excerpt, results are fake):
+
+----
+$ ./support/scripts/test-pkg -c libcurl.config -p libcurl
+                armv5-ctng-linux-gnueabi: OK
+              armv7-ctng-linux-gnueabihf: OK
+                        br-aarch64-glibc: SKIPPED
+                           br-arcle-hs38: SKIPPED
+                            br-arm-basic: FAILED
+                  br-arm-cortex-a9-glibc: OK
+                   br-arm-cortex-a9-musl: FAILED
+                   br-arm-cortex-m4-full: OK
+                             br-arm-full: OK
+                    br-arm-full-nothread: OK
+                      br-arm-full-static: OK
+11 builds, 2 skipped, 2 failed
+----
+
+The results mean:
+
+* `OK`: the build was successful
+* `SKIPPED`: one or more config options from the config snippet were
+  missing in the resulting configuration; inspect the file +config.missing+
+  in the output build directory (+~/br-test-pkg/TOOLCHAIN_NAME/+ by
+  default)
+* `FAILED`: the build failed for one of various reasons; in either case,
+  inspect the +logfile+ file in the output build  directory:
+** the actual build failed,
+** one of the preliminary steps (download the config file, apply the
+   configuration, running `dirclean` for the package) failed;
+
+When there are failures, you can just re-run the script with the same
+options (after you fixed your package); the script will attempt to re-build
+the package for all toolchains, without the need to re-build all the
+dependencies of that package (but it requires the +-p+ optiopn, see below).
+
+The +test-pkg+ script accepts a few options, for which you can get some
+help by running:
+
+----
+$ ./support/scripts/test-pkg -h
+----
 
 [[github-download-url]]
 ==== How to add a package from GitHub
-- 
2.7.4

[Buildroot] [PATCH 2/7 v4] support/test-pkg: add option to use an alternate list of toolchains

[Yann E. MORIN]

For now, testing a package requires network access. However, there are
situations where everything is already cached locally (especially the
toolchains tarballs) and network is not available (e.g. in the train,
travelling back from FOSDEM...)

Alternatively, one may also want to test against a subset of the default
toolchains (e.g. the ones known to have a specific issue).

Add an option to use an alternate URL, which can be remote or a path to
a local file.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 support/scripts/test-pkg | 47 +++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 41 insertions(+), 6 deletions(-)

diff --git a/support/scripts/test-pkg b/support/scripts/test-pkg
index a040ce1..9626c1a 100755
--- a/support/scripts/test-pkg
+++ b/support/scripts/test-pkg
@@ -5,16 +5,17 @@ TOOLCHAINS_URL='http://autobuild.buildroot.org/toolchains/configs/toolchain-conf
 
 main() {
     local o O opts
-    local cfg dir pkg random toolchain
+    local cfg dir pkg random url toolchain
     local ret nb nb_skip nb_fail
     local -a toolchains
 
-    o='hc:d:p:r:'
-    O='help,config-snippet:build-dir:package:,random:'
+    o='hc:d:p:r:t:'
+    O='help,config-snippet:build-dir:package:,random:,toolchains:'
     opts="$(getopt -n "${my_name}" -o "${o}" -l "${O}" -- "${@}")"
     eval set -- "${opts}"
 
     random=0
+    url="${TOOLCHAINS_URL}"
     while [ ${#} -gt 0 ]; do
         case "${1}" in
         (-h|--help)
@@ -32,6 +33,9 @@ main() {
         (-r|--random)
             random="${2}"; shift 2
             ;;
+        (-t|--toolchains)
+            url="${2}"; shift 2
+            ;;
         (--)
             shift; break
             ;;
@@ -47,10 +51,16 @@ main() {
         dir="${HOME}/br-test-pkg"
     fi
 
+    # Transform local paths to URI to make curl happy and simplify
+    # our code path
+    case "${url}" in
+    (/*)    url="file://${url}";;
+    esac
+
     # Extract the URLs of the toolchains; drop internal toolchains
     # E.g.: http://server/path/to/name.config,arch,libc
     #  -->  http://server/path/to/name.config
-    toolchains=($(curl -s "${TOOLCHAINS_URL}" \
+    toolchains=($(curl -s "${url}" \
                   |sed -r -e 's/,.*//; /internal/d;' \
                   |if [ ${random} -gt 0 ]; then \
                       sort -R |head -n ${random}
@@ -87,6 +97,12 @@ build_one() {
     local pkg="${4}"
     local toolchain
 
+    # Transform local paths to URI to make curl happy and simplify
+    # our code path
+    case "${url}" in
+    (/*)    url="file://${url}";;
+    esac
+
     # Using basename(1) on a URL works nicely
     toolchain="$(basename "${url}" .config)"
 
@@ -156,8 +172,22 @@ In case failures are noticed, you can fix the package and just re-run the
 same command again; it will re-run the test where it failed. If you did
 specify a package (with -p), the package build dir will be removed first.
 
-The list of toolchains is retrieved from the Buildroot autobuilders, available
-at ${TOOLCHAINS_URL}.
+Unless specified with -t, the list of toolchains is retrieved from the
+Buildroot autobuilders, available at:
+    ${TOOLCHAINS_URL}
+
+The list of toolchains should contain the URLs to all toolchains, one per
+line, along with the architecture and C library used, separated by commas,
+"URL,ARCH,LIBC" (only the first field, URL, is used by this script). For
+example:
+
+    https://server/path/to/toolchain-1.config,arm,glibc
+    /path/to/local-toolchain.config,i386,musl
+
+The URL for each toolchain should point to a .config file that contains
+only the toolchain and architecture settings. URLs that contain the string
+'internal' are skipped, on the assumption that the configuration would
+build an internal toolchain (which takes a lot of time).
 
 Options:
 
@@ -179,6 +209,11 @@ Options:
         Limit the tests to the N randomly selected toolchains, instead of
         building with all toolchains.
 
+    -t URL, --toolchains URL
+        Use the toolchains described at URL instead of the toolchains used
+        by the Buildroot autobuilders (see above). URL can be a path to a
+        local file.
+
 Example:
 
     Testing libcec would require a config snippet that contains:
-- 
2.7.4

[Buildroot] [PATCH 3/7 v4] support/test-pkg: print number of toolchain and progress

[Yann E. MORIN]

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
---
 docs/manual/adding-packages-tips.txt | 22 +++++++++++-----------
 support/scripts/test-pkg             | 24 +++++++++---------------
 2 files changed, 20 insertions(+), 26 deletions(-)

diff --git a/docs/manual/adding-packages-tips.txt b/docs/manual/adding-packages-tips.txt
index 732904f..61cf0bf 100644
--- a/docs/manual/adding-packages-tips.txt
+++ b/docs/manual/adding-packages-tips.txt
@@ -84,17 +84,17 @@ result (excerpt, results are fake):
 
 ----
 $ ./support/scripts/test-pkg -c libcurl.config -p libcurl
-                armv5-ctng-linux-gnueabi: OK
-              armv7-ctng-linux-gnueabihf: OK
-                        br-aarch64-glibc: SKIPPED
-                           br-arcle-hs38: SKIPPED
-                            br-arm-basic: FAILED
-                  br-arm-cortex-a9-glibc: OK
-                   br-arm-cortex-a9-musl: FAILED
-                   br-arm-cortex-m4-full: OK
-                             br-arm-full: OK
-                    br-arm-full-nothread: OK
-                      br-arm-full-static: OK
+                armv5-ctng-linux-gnueabi [ 1/11]: OK
+              armv7-ctng-linux-gnueabihf [ 2/11]: OK
+                        br-aarch64-glibc [ 3/11]: SKIPPED
+                           br-arcle-hs38 [ 4/11]: SKIPPED
+                            br-arm-basic [ 5/11]: FAILED
+                  br-arm-cortex-a9-glibc [ 6/11]: OK
+                   br-arm-cortex-a9-musl [ 7/11]: FAILED
+                   br-arm-cortex-m4-full [ 8/11]: OK
+                             br-arm-full [ 9/11]: OK
+                    br-arm-full-nothread [10/11]: OK
+                      br-arm-full-static [11/11]: OK
 11 builds, 2 skipped, 2 failed
 ----
 
diff --git a/support/scripts/test-pkg b/support/scripts/test-pkg
index 9626c1a..965ddaf 100755
--- a/support/scripts/test-pkg
+++ b/support/scripts/test-pkg
@@ -6,7 +6,7 @@ TOOLCHAINS_URL='http://autobuild.buildroot.org/toolchains/configs/toolchain-conf
 main() {
     local o O opts
     local cfg dir pkg random url toolchain
-    local ret nb nb_skip nb_fail
+    local ret nb nb_skip nb_fail nb_tc
     local -a toolchains
 
     o='hc:d:p:r:t:'
@@ -70,7 +70,8 @@ main() {
                  )
                )
 
-    if [ ${#toolchains[@]} -eq 0 ]; then
+    nb_tc="${#toolchains[@]}"
+    if [ ${nb_tc} -eq 0 ]; then
         printf "error: no toolchain found (networking issue?)\n" >&2; exit 1
     fi
 
@@ -78,13 +79,15 @@ main() {
     nb_skip=0
     nb_fail=0
     for toolchain in "${toolchains[@]}"; do
+        : $((nb++))
+        printf "%40s [%*d/%d]: " "$(basename "${toolchain}" .config)" \
+                                 ${#nb_tc} ${nb} ${nb_tc}
         build_one "${dir}" "${toolchain}" "${cfg}" "${pkg}" && ret=0 || ret=${?}
         case ${ret} in
-        (0) ;;
-        (1) : $((nb_skip++));;
-        (2) : $((nb_fail++));;
+        (0) printf "OK\n";;
+        (1) : $((nb_skip++)); printf "SKIPPED\n";;
+        (2) : $((nb_fail++)); printf "FAILED\n";;
         esac
-        : $((nb++))
     done
 
     printf "%d builds, %d skipped, %d failed\n" ${nb} ${nb_skip} ${nb_fail}
@@ -106,13 +109,10 @@ build_one() {
     # Using basename(1) on a URL works nicely
     toolchain="$(basename "${url}" .config)"
 
-    printf "%40s: " "${toolchain}"
-
     dir="${dir}/${toolchain}"
     mkdir -p "${dir}"
 
     if ! curl -s "${url}" >"${dir}/.config"; then
-        printf "FAILED\n"
         return 2
     fi
 
@@ -125,7 +125,6 @@ build_one() {
     cat "${cfg}" >>"${dir}/.config"
 
     if ! make O="${dir}" olddefconfig >/dev/null 2>&1; then
-        printf "FAILED\n"
         return 2
     fi
     # We want all the options from the snippet to be present as-is (set
@@ -136,7 +135,6 @@ build_one() {
     # done in the same locale.
     comm -23 <(sort "${cfg}") <(sort "${dir}/.config") >"${dir}/missing.config"
     if [ -s "${dir}/missing.config" ]; then
-        printf "SKIPPED\n"
         return 1
     fi
     # Remove file, it's empty anyway.
@@ -144,18 +142,14 @@ build_one() {
 
     if [ -n "${pkg}" ]; then
         if ! make O="${dir}" "${pkg}-dirclean" >> "${dir}/logfile" 2>&1; then
-            printf "FAILED\n"
             return 2
         fi
     fi
 
     # shellcheck disable=SC2086
     if ! make O="${dir}" ${pkg} >> "${dir}/logfile" 2>&1; then
-        printf "FAILED\n"
         return 2
     fi
-
-    printf "OK\n"
 }
 
 help() {
-- 
2.7.4

[Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements

[Yann E. MORIN]

Hello All!

This series brings a few fixes and improvements to the test-pkg script.

Changes v3 -> v4:
  - drop patches already applied
  - run legal-info as well  (Romain, Thomas)
  - add anentry in the manual  (Thomas)
  - misc cleanups in 3 new patches

Changes v2 -> v3:
  - drop patches already applied
  - simplify the config check  (Cam)
  - be less verbose  (Thomas)
  - fix coding style  (Thomas)

Changes v2 -> v3:
  - simplify the code to store missing config lines  (Luca)
  - properly run when -r is not provided
  - add 5th path to use an alternate list
  - add 6th patch to print the progress [n/N] for each toolchain


Regards,
Yann E. MORIN.


The following changes since commit 8ae3dce5275915a1784b00bf145af907827fed0d

  postgresql: disable spinlocks on openrisc (2017-02-15 22:34:44 +0100)


are available in the git repository at:

  git://git.buildroot.org/~ymorin/git/buildroot.git

for you to fetch changes up to 58d4b1a3fa0de47c84ee8bc281d3b89edfe5b40c

  support/test-pkg: run legal-info (2017-02-15 22:37:30 +0100)


----------------------------------------------------------------
Yann E. MORIN (7):
      docs/manual: document the test-pkg script
      support/test-pkg: add option to use an alternate list of toolchains
      support/test-pkg: print number of toolchain and progress
      support/test-pkg: the list of toolchains really contains URLs
      support/test-pkg: cannonicalize paths early
      support/test-pkg: create build dir from caller
      support/test-pkg: run legal-info

 docs/manual/adding-packages-tips.txt |  91 +++++++++++++++++++++++++++++++
 support/scripts/test-pkg             | 101 +++++++++++++++++++++++------------
 2 files changed, 159 insertions(+), 33 deletions(-)

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 4/7 v4] support/test-pkg: the list of toolchains really contains URLs

[Yann E. MORIN]

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 support/scripts/test-pkg | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/support/scripts/test-pkg b/support/scripts/test-pkg
index 965ddaf..5714afa 100755
--- a/support/scripts/test-pkg
+++ b/support/scripts/test-pkg
@@ -78,11 +78,11 @@ main() {
     nb=0
     nb_skip=0
     nb_fail=0
-    for toolchain in "${toolchains[@]}"; do
+    for url in "${toolchains[@]}"; do
         : $((nb++))
-        printf "%40s [%*d/%d]: " "$(basename "${toolchain}" .config)" \
+        printf "%40s [%*d/%d]: " "$(basename "${url}" .config)" \
                                  ${#nb_tc} ${nb} ${nb_tc}
-        build_one "${dir}" "${toolchain}" "${cfg}" "${pkg}" && ret=0 || ret=${?}
+        build_one "${dir}" "${url}" "${cfg}" "${pkg}" && ret=0 || ret=${?}
         case ${ret} in
         (0) printf "OK\n";;
         (1) : $((nb_skip++)); printf "SKIPPED\n";;
-- 
2.7.4

[Buildroot] [PATCH 5/7 v4] support/test-pkg: cannonicalize paths early

[Yann E. MORIN]

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 support/scripts/test-pkg | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/support/scripts/test-pkg b/support/scripts/test-pkg
index 5714afa..d65cfe2 100755
--- a/support/scripts/test-pkg
+++ b/support/scripts/test-pkg
@@ -57,16 +57,21 @@ main() {
     (/*)    url="file://${url}";;
     esac
 
-    # Extract the URLs of the toolchains; drop internal toolchains
+    # Extract the URLs of the toolchains; drop internal toolchains,
     # E.g.: http://server/path/to/name.config,arch,libc
     #  -->  http://server/path/to/name.config
+    # then change local paths to URI
+    # E.g.: /path/toname.config
+    #  -->  file:///path/toname.config
     toolchains=($(curl -s "${url}" \
                   |sed -r -e 's/,.*//; /internal/d;' \
                   |if [ ${random} -gt 0 ]; then \
                       sort -R |head -n ${random}
                    else
                       cat
-                   fi |sort
+                   fi \
+                  |sort \
+                  |sed -r -e 's,^/,file:///,'
                  )
                )
 
@@ -100,12 +105,6 @@ build_one() {
     local pkg="${4}"
     local toolchain
 
-    # Transform local paths to URI to make curl happy and simplify
-    # our code path
-    case "${url}" in
-    (/*)    url="file://${url}";;
-    esac
-
     # Using basename(1) on a URL works nicely
     toolchain="$(basename "${url}" .config)"
 
-- 
2.7.4

[Buildroot] [PATCH 6/7 v4] support/test-pkg: create build dir from caller

[Yann E. MORIN]

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 support/scripts/test-pkg | 18 +++++++-----------
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/support/scripts/test-pkg b/support/scripts/test-pkg
index d65cfe2..8435848 100755
--- a/support/scripts/test-pkg
+++ b/support/scripts/test-pkg
@@ -6,7 +6,7 @@ TOOLCHAINS_URL='http://autobuild.buildroot.org/toolchains/configs/toolchain-conf
 main() {
     local o O opts
     local cfg dir pkg random url toolchain
-    local ret nb nb_skip nb_fail nb_tc
+    local ret nb nb_skip nb_fail nb_tc build_dir
     local -a toolchains
 
     o='hc:d:p:r:t:'
@@ -85,9 +85,12 @@ main() {
     nb_fail=0
     for url in "${toolchains[@]}"; do
         : $((nb++))
-        printf "%40s [%*d/%d]: " "$(basename "${url}" .config)" \
-                                 ${#nb_tc} ${nb} ${nb_tc}
-        build_one "${dir}" "${url}" "${cfg}" "${pkg}" && ret=0 || ret=${?}
+        # Using basename(1) on a URL works nicely
+        toolchain="$(basename "${url}" .config)"
+        build_dir="${dir}/${toolchain}"
+        mkdir -p "${build_dir}"
+        printf "%40s [%*d/%d]: " "${toolchain}" ${#nb_tc} ${nb} ${nb_tc}
+        build_one "${build_dir}" "${url}" "${cfg}" "${pkg}" && ret=0 || ret=${?}
         case ${ret} in
         (0) printf "OK\n";;
         (1) : $((nb_skip++)); printf "SKIPPED\n";;
@@ -103,13 +106,6 @@ build_one() {
     local url="${2}"
     local cfg="${3}"
     local pkg="${4}"
-    local toolchain
-
-    # Using basename(1) on a URL works nicely
-    toolchain="$(basename "${url}" .config)"
-
-    dir="${dir}/${toolchain}"
-    mkdir -p "${dir}"
 
     if ! curl -s "${url}" >"${dir}/.config"; then
         return 2
-- 
2.7.4

[Buildroot] [PATCH 7/7 v4] support/test-pkg: run legal-info

[Yann E. MORIN]

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 docs/manual/adding-packages-tips.txt |  5 +++--
 support/scripts/test-pkg             | 15 +++++++++++++--
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/docs/manual/adding-packages-tips.txt b/docs/manual/adding-packages-tips.txt
index 61cf0bf..34d861c 100644
--- a/docs/manual/adding-packages-tips.txt
+++ b/docs/manual/adding-packages-tips.txt
@@ -93,9 +93,9 @@ $ ./support/scripts/test-pkg -c libcurl.config -p libcurl
                    br-arm-cortex-a9-musl [ 7/11]: FAILED
                    br-arm-cortex-m4-full [ 8/11]: OK
                              br-arm-full [ 9/11]: OK
-                    br-arm-full-nothread [10/11]: OK
+                    br-arm-full-nothread [10/11]: FAILED
                       br-arm-full-static [11/11]: OK
-11 builds, 2 skipped, 2 failed
+11 builds, 2 skipped, 2 build failed, 1 legal-info failed
 ----
 
 The results mean:
@@ -108,6 +108,7 @@ The results mean:
 * `FAILED`: the build failed for one of various reasons; in either case,
   inspect the +logfile+ file in the output build  directory:
 ** the actual build failed,
+** the legal-info failed,
 ** one of the preliminary steps (download the config file, apply the
    configuration, running `dirclean` for the package) failed;
 
diff --git a/support/scripts/test-pkg b/support/scripts/test-pkg
index 8435848..56728ae 100755
--- a/support/scripts/test-pkg
+++ b/support/scripts/test-pkg
@@ -6,7 +6,7 @@ TOOLCHAINS_URL='http://autobuild.buildroot.org/toolchains/configs/toolchain-conf
 main() {
     local o O opts
     local cfg dir pkg random url toolchain
-    local ret nb nb_skip nb_fail nb_tc build_dir
+    local ret nb nb_skip nb_fail nb_legal nb_tc build_dir
     local -a toolchains
 
     o='hc:d:p:r:t:'
@@ -83,6 +83,7 @@ main() {
     nb=0
     nb_skip=0
     nb_fail=0
+    nb_legal=0
     for url in "${toolchains[@]}"; do
         : $((nb++))
         # Using basename(1) on a URL works nicely
@@ -95,10 +96,12 @@ main() {
         (0) printf "OK\n";;
         (1) : $((nb_skip++)); printf "SKIPPED\n";;
         (2) : $((nb_fail++)); printf "FAILED\n";;
+        (3) : $((nb_legal++)); printf "FAILED\n";;
         esac
     done
 
-    printf "%d builds, %d skipped, %d failed\n" ${nb} ${nb_skip} ${nb_fail}
+    printf "%d builds, %d skipped, %d build failed, %d legal-info failed\n" \
+        ${nb} ${nb_skip} ${nb_fail} ${nb_legal}
 }
 
 build_one() {
@@ -145,6 +148,14 @@ build_one() {
     if ! make O="${dir}" ${pkg} >> "${dir}/logfile" 2>&1; then
         return 2
     fi
+
+    # legal-info done systematically, because some packages have different
+    # sources depending on the configuration (e.g. lua-5.2 vs. lua-5.3)
+    if [ -n "${pkg}" ]; then
+        if ! make O="${dir}" "${pkg}-legal-info" >> "${dir}/logfile" 2>&1; then
+            return 3
+        fi
+    fi
 }
 
 help() {
-- 
2.7.4

[Buildroot] [PATCH 1/7 v4] docs/manual: document the test-pkg script

[Thomas Petazzoni]

Hello,

Thanks for this update!

On Wed, 15 Feb 2017 22:44:29 +0100, Yann E. MORIN wrote:

> +First, create a config snippet that contains all the necessary options
> +needed to enabel your package, but without any architecture or toolchain

enable

> +The results mean:
> +
> +* `OK`: the build was successful
> +* `SKIPPED`: one or more config options from the config snippet were
> +  missing in the resulting configuration; inspect the file +config.missing+
> +  in the output build directory (+~/br-test-pkg/TOOLCHAIN_NAME/+ by
> +  default)

I would expand this explanation a bit here. As you wrote it might seem
like it is not normal for a toolchain to be skipped. What about instead:

 `SKIPPED`: one or more configuration options listed in the config
 snipped were not present in the final configuration. This is due to
 options having dependencies not satisfied by the toolchain, such as
 for example a package that +depends on BR2_USE_MMU+ with a noMMU
 toolchain.

> +When there are failures, you can just re-run the script with the same
> +options (after you fixed your package); the script will attempt to re-build
> +the package for all toolchains, without the need to re-build all the
> +dependencies of that package (but it requires the +-p+ optiopn, see below).

"see below" ? but there's nothing below.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 1/7 v4] docs/manual: document the test-pkg script

[Yann E. MORIN]

Thomas, All,

On 2017-02-15 23:25 +0100, Thomas Petazzoni spake thusly:
> On Wed, 15 Feb 2017 22:44:29 +0100, Yann E. MORIN wrote:
[--SNIP--]
> > +The results mean:
> > +
> > +* `OK`: the build was successful
> > +* `SKIPPED`: one or more config options from the config snippet were
> > +  missing in the resulting configuration; inspect the file +config.missing+
> > +  in the output build directory (+~/br-test-pkg/TOOLCHAIN_NAME/+ by
> > +  default)
> 
> I would expand this explanation a bit here. As you wrote it might seem
> like it is not normal for a toolchain to be skipped. What about instead:
> 
>  `SKIPPED`: one or more configuration options listed in the config
>  snipped were not present in the final configuration. This is due to
>  options having dependencies not satisfied by the toolchain, such as
>  for example a package that +depends on BR2_USE_MMU+ with a noMMU
>  toolchain.

Very good, thanks! :-)

I'll keep the part that says where such missing options are stored,
though.

> > +When there are failures, you can just re-run the script with the same
> > +options (after you fixed your package); the script will attempt to re-build
> > +the package for all toolchains, without the need to re-build all the
> > +dependencies of that package (but it requires the +-p+ optiopn, see below).
> 
> "see below" ? but there's nothing below.

Doh... I initially listed all the options in a paragraph below, but
decided against, because it was duplicating the help text of the script
and instead just instructed the user to run the script with -h.

And I forgot to remove that blurb here. Will fix.

Actually, I think that running the script without specifying the package
is incorrect. One can not expect to restart correctly in this case.

For example, say package A has a dependency on package B, but the user
forgot to add it in A_DEPEDENCIES. The buildsystem of the package if
foobared enough that it incorrectly checks at configure time, but uses
configure-time variables to link with a lib (this situation does happen).

The build fails, the user fixes the dependencies, and rstart the build.
But then, configure is not run, and the build still fails, which leaves
the user in the dark...

While specifying the package ensures the build wil start afresh for that
package thanks to the dirclean.

Thoughts?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements

[Arnout Vandecappelle]

On 15-02-17 22:44, Yann E. MORIN wrote:
> Hello All!
> 
> This series brings a few fixes and improvements to the test-pkg script.

 I was going to modify test-pkg to use the toolchains from configs/toolchains,
but then I noticed this series was still not committed. It obviously conflicts
heavily with what I'm going to do, so I'm taking this over, OK?

[snip]

> ----------------------------------------------------------------
> Yann E. MORIN (7):
>       docs/manual: document the test-pkg script

 I'll include Thomas's feedback, plus some more fixes from me.

>       support/test-pkg: add option to use an alternate list of toolchains

 I'll drop this, since we're not going to get toolchains from a URL anymore. IMO
the same feature can easily be achieved by having a directory with toolchain
configs inside the tree (or inside an external tree).

>       support/test-pkg: print number of toolchain and progress
>       support/test-pkg: the list of toolchains really contains URLs

 With the toolchain URLs gone, this is not true anymore.

>       support/test-pkg: cannonicalize paths early

 With the toolchain URLs gone, this is not relevant anymore.

>       support/test-pkg: create build dir from caller

 Took me a while to figure out what this patch was doing, so I'll reword the
commit message.


 Regards,
 Arnout

>       support/test-pkg: run legal-info
> 
>  docs/manual/adding-packages-tips.txt |  91 +++++++++++++++++++++++++++++++
>  support/scripts/test-pkg             | 101 +++++++++++++++++++++++------------
>  2 files changed, 159 insertions(+), 33 deletions(-)
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements

[Yann E. MORIN]

Arnout,

On 2017-04-05 16:37 +0200, Arnout Vandecappelle spake thusly:
> On 15-02-17 22:44, Yann E. MORIN wrote:
> > Hello All!
> > 
> > This series brings a few fixes and improvements to the test-pkg script.
> 
>  I was going to modify test-pkg to use the toolchains from configs/toolchains,
> but then I noticed this series was still not committed. It obviously conflicts
> heavily with what I'm going to do, so I'm taking this over, OK?

As you wish.

The latest version (which I did not yet post, did I?) is available, as
usual, on my git tree:

    git://git.busybox.net/~ymorin/git/buildroot   yem/test-pkg

> > ----------------------------------------------------------------
> > Yann E. MORIN (7):
> >       docs/manual: document the test-pkg script
> 
>  I'll include Thomas's feedback, plus some more fixes from me.

I think I already addresses Thomas' comments in the latest version.

Regards,
Yann E. MORIN.

> >       support/test-pkg: add option to use an alternate list of toolchains
> 
>  I'll drop this, since we're not going to get toolchains from a URL anymore. IMO
> the same feature can easily be achieved by having a directory with toolchain
> configs inside the tree (or inside an external tree).

Well, as long as I can specify a list of toolchains, that is not the
default, that's fine. If I just have to do a wget to have a local file,
I'm OK with that.

But I *want* to be able to use a custom list of toolchains.

> >       support/test-pkg: print number of toolchain and progress
> >       support/test-pkg: the list of toolchains really contains URLs
> 
>  With the toolchain URLs gone, this is not true anymore.

Well, I am not sure what you meant: we can't have a list of remote
config files to use anymore? That is sad... :-(

> >       support/test-pkg: cannonicalize paths early
> 
>  With the toolchain URLs gone, this is not relevant anymore.
> 
> >       support/test-pkg: create build dir from caller
> 
>  Took me a while to figure out what this patch was doing, so I'll reword the
> commit message.

Ah yes, sorry, the commit log is a bit terse... :-/

Please note that there is another patch on the series now:

    support/test-pkg: run legal-info

    https://git.buildroot.org/~ymorin/git/buildroot/commit/?h=yem/test-pkg&id=8a9fec1b939caad8ad282a94e6049c748eff5336

Regards,
Yann E. MORIN.

> 
>  Regards,
>  Arnout
> 
> >       support/test-pkg: run legal-info
> > 
> >  docs/manual/adding-packages-tips.txt |  91 +++++++++++++++++++++++++++++++
> >  support/scripts/test-pkg             | 101 +++++++++++++++++++++++------------
> >  2 files changed, 159 insertions(+), 33 deletions(-)
> > 
> 
> -- 
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements

[Arnout Vandecappelle]

On 05-04-17 21:16, Yann E. MORIN wrote:
> Arnout,
> 
> On 2017-04-05 16:37 +0200, Arnout Vandecappelle spake thusly:
>> On 15-02-17 22:44, Yann E. MORIN wrote:
>>> Hello All!
>>>
>>> This series brings a few fixes and improvements to the test-pkg script.
>>
>>  I was going to modify test-pkg to use the toolchains from configs/toolchains,
>> but then I noticed this series was still not committed. It obviously conflicts
>> heavily with what I'm going to do, so I'm taking this over, OK?
> 
> As you wish.
> 
> The latest version (which I did not yet post, did I?) is available, as
> usual, on my git tree:
> 
>     git://git.busybox.net/~ymorin/git/buildroot   yem/test-pkg

 Argh, I should have checked for that before starting my work... Your commits
don't have a version log, do you have any idea if anything changed except for
the first patch?

> 
>>> ----------------------------------------------------------------
>>> Yann E. MORIN (7):
>>>       docs/manual: document the test-pkg script
>>
>>  I'll include Thomas's feedback, plus some more fixes from me.
> 
> I think I already addresses Thomas' comments in the latest version.
> 
> Regards,
> Yann E. MORIN.
> 
>>>       support/test-pkg: add option to use an alternate list of toolchains
>>
>>  I'll drop this, since we're not going to get toolchains from a URL anymore. IMO
>> the same feature can easily be achieved by having a directory with toolchain
>> configs inside the tree (or inside an external tree).
> 
> Well, as long as I can specify a list of toolchains, that is not the
> default, that's fine. If I just have to do a wget to have a local file,
> I'm OK with that.
> 
> But I *want* to be able to use a custom list of toolchains.

 You don't need to get it from a URL, do you? I think having the list of
toolchains passed as a BR2_EXTERNAL is much more appropriate. Basically, I now have

TOOLCHAINS_PATH=configs/toolchains

which points to a directory containing toolchain configs. I can add an option
that allows you to override that directory. I don't see much point in getting
this from a URL, is there?

> 
>>>       support/test-pkg: print number of toolchain and progress
>>>       support/test-pkg: the list of toolchains really contains URLs
>>
>>  With the toolchain URLs gone, this is not true anymore.
> 
> Well, I am not sure what you meant: we can't have a list of remote
> config files to use anymore? That is sad... :-(

 Can you explain your use case for a list of *remote* config files?

> 
>>>       support/test-pkg: cannonicalize paths early
>>
>>  With the toolchain URLs gone, this is not relevant anymore.
>>
>>>       support/test-pkg: create build dir from caller
>>
>>  Took me a while to figure out what this patch was doing, so I'll reword the
>> commit message.
> 
> Ah yes, sorry, the commit log is a bit terse... :-/
> 
> Please note that there is another patch on the series now:
> 
>     support/test-pkg: run legal-info

 It was already there (see below).


 Regards,
 Arnout

> 
>     https://git.buildroot.org/~ymorin/git/buildroot/commit/?h=yem/test-pkg&id=8a9fec1b939caad8ad282a94e6049c748eff5336
> 
> Regards,
> Yann E. MORIN.
> 
>>
>>  Regards,
>>  Arnout
>>
>>>       support/test-pkg: run legal-info
>>>
>>>  docs/manual/adding-packages-tips.txt |  91 +++++++++++++++++++++++++++++++
>>>  support/scripts/test-pkg             | 101 +++++++++++++++++++++++------------
>>>  2 files changed, 159 insertions(+), 33 deletions(-)
>>>
>>
>> -- 
>> Arnout Vandecappelle                          arnout at mind be
>> Senior Embedded Software Architect            +32-16-286500
>> Essensium/Mind                                http://www.mind.be
>> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
>> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
>> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements

[Yann E. MORIN]

Arnout, All,

On 2017-04-06 10:48 +0200, Arnout Vandecappelle spake thusly:
> On 05-04-17 21:16, Yann E. MORIN wrote:
> > On 2017-04-05 16:37 +0200, Arnout Vandecappelle spake thusly:
> >>  I was going to modify test-pkg to use the toolchains from configs/toolchains,
> >> but then I noticed this series was still not committed. It obviously conflicts
> >> heavily with what I'm going to do, so I'm taking this over, OK?
> > The latest version (which I did not yet post, did I?) is available, as
> > usual, on my git tree:
> >     git://git.busybox.net/~ymorin/git/buildroot   yem/test-pkg
>  Argh, I should have checked for that before starting my work... Your commits
> don't have a version log, do you have any idea if anything changed except for
> the first patch?

Given that the first patch does have a changelog, but the others do not,
I guess nothing of great interest... :-/

> > Well, as long as I can specify a list of toolchains, that is not the
> > default, that's fine. If I just have to do a wget to have a local file,
> > I'm OK with that.
> > 
> > But I *want* to be able to use a custom list of toolchains.
> 
>  You don't need to get it from a URL, do you? I think having the list of
> toolchains passed as a BR2_EXTERNAL is much more appropriate. Basically, I now have
> 
> TOOLCHAINS_PATH=configs/toolchains

Please, make that an option to the script, not an environment variable!

    --toolchains-dir=/path/to/configs/toolchains

> which points to a directory containing toolchain configs. I can add an option
> that allows you to override that directory. I don't see much point in getting
> this from a URL, is there?

Well, if I can use a custom list of toolchians, I'm fine. Now, that I
need to pre-populate that directory by myself is acceptable. If I need
to store the toolchain configs remotely, it now behooves to me to
download them fiurst and feed local files to the script. That's OK.

> >>>       support/test-pkg: print number of toolchain and progress
> >>>       support/test-pkg: the list of toolchains really contains URLs
> >>  With the toolchain URLs gone, this is not true anymore.
> > Well, I am not sure what you meant: we can't have a list of remote
> > config files to use anymore? That is sad... :-(
>  Can you explain your use case for a list of *remote* config files?

It's just that my "tool_s_" are stored in their own repositor_ies_...

Regards,
Yann E. MORIN.

> > Please note that there is another patch on the series now:
> >     support/test-pkg: run legal-info
>  It was already there (see below).

/me rubs his eyes...
Ah, right...

Regards,
Yann E. MORIN.

>  Regards,
>  Arnout
> 
> > 
> >     https://git.buildroot.org/~ymorin/git/buildroot/commit/?h=yem/test-pkg&id=8a9fec1b939caad8ad282a94e6049c748eff5336
> > 
> > Regards,
> > Yann E. MORIN.
> > 
> >>
> >>  Regards,
> >>  Arnout
> >>
> >>>       support/test-pkg: run legal-info
> >>>
> >>>  docs/manual/adding-packages-tips.txt |  91 +++++++++++++++++++++++++++++++
> >>>  support/scripts/test-pkg             | 101 +++++++++++++++++++++++------------
> >>>  2 files changed, 159 insertions(+), 33 deletions(-)
> >>>
> >>
> >> -- 
> >> Arnout Vandecappelle                          arnout at mind be
> >> Senior Embedded Software Architect            +32-16-286500
> >> Essensium/Mind                                http://www.mind.be
> >> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> >> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> >> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
> > 
> 
> -- 
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements

[Arnout Vandecappelle]

On 06-04-17 17:55, Yann E. MORIN wrote:
> Arnout, All,
> 
> On 2017-04-06 10:48 +0200, Arnout Vandecappelle spake thusly:
>> On 05-04-17 21:16, Yann E. MORIN wrote:
[snip]
>>> Well, as long as I can specify a list of toolchains, that is not the
>>> default, that's fine. If I just have to do a wget to have a local file,
>>> I'm OK with that.
>>>
>>> But I *want* to be able to use a custom list of toolchains.
>>
>>  You don't need to get it from a URL, do you? I think having the list of
>> toolchains passed as a BR2_EXTERNAL is much more appropriate. Basically, I now have
>>
>> TOOLCHAINS_PATH=configs/toolchains
> 
> Please, make that an option to the script, not an environment variable!

 That's what I wanted to do, of course.

> 
>     --toolchains-dir=/path/to/configs/toolchains

 Thanks for the naming tip, I would have chosen something much more stupid.

> 
>> which points to a directory containing toolchain configs. I can add an option
>> that allows you to override that directory. I don't see much point in getting
>> this from a URL, is there?
> 
> Well, if I can use a custom list of toolchians, I'm fine. Now, that I
> need to pre-populate that directory by myself is acceptable. If I need
> to store the toolchain configs remotely, it now behooves to me to
> download them fiurst and feed local files to the script. That's OK.

 Yeah, and you can also make a link farm if needed.

> 
>>>>>       support/test-pkg: print number of toolchain and progress
>>>>>       support/test-pkg: the list of toolchains really contains URLs
>>>>  With the toolchain URLs gone, this is not true anymore.
>>> Well, I am not sure what you meant: we can't have a list of remote
>>> config files to use anymore? That is sad... :-(
>>  Can you explain your use case for a list of *remote* config files?
> 
> It's just that my "tool_s_" are stored in their own repositor_ies_...

 But do those repositories contain toolchain.config files? They would typically
contain the config file for building the toolchain, not for using it as an
external toolchain, right?

 Some extra extensions that would be nice:

- specifying a shell glob pattern to match the toolchain;

- once we have a tool that can calculate the custom external toolchain
arguments: specify a list of toolchain tarball URLs and download derive the
toolchain_defconfig from there.


 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF