* [Buildroot] [PATCH 1/7 v4] docs/manual: document the test-pkg script
2017-02-15 21:44 [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements Yann E. MORIN
@ 2017-02-15 21:44 ` Yann E. MORIN
2017-02-15 22:25 ` Thomas Petazzoni
2017-02-15 21:44 ` [Buildroot] [PATCH 2/7 v4] support/test-pkg: add option to use an alternate list of toolchains Yann E. MORIN
` (6 subsequent siblings)
7 siblings, 1 reply; 15+ messages in thread
From: Yann E. MORIN @ 2017-02-15 21:44 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply related [flat|nested] 15+ messages in thread* [Buildroot] [PATCH 1/7 v4] docs/manual: document the test-pkg script
2017-02-15 21:44 ` [Buildroot] [PATCH 1/7 v4] docs/manual: document the test-pkg script Yann E. MORIN
@ 2017-02-15 22:25 ` Thomas Petazzoni
2017-02-16 17:21 ` Yann E. MORIN
0 siblings, 1 reply; 15+ messages in thread
From: Thomas Petazzoni @ 2017-02-15 22:25 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] [PATCH 1/7 v4] docs/manual: document the test-pkg script
2017-02-15 22:25 ` Thomas Petazzoni
@ 2017-02-16 17:21 ` Yann E. MORIN
0 siblings, 0 replies; 15+ messages in thread
From: Yann E. MORIN @ 2017-02-16 17:21 UTC (permalink / raw)
To: buildroot
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. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] [PATCH 2/7 v4] support/test-pkg: add option to use an alternate list of toolchains
2017-02-15 21:44 [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements Yann E. MORIN
2017-02-15 21:44 ` [Buildroot] [PATCH 1/7 v4] docs/manual: document the test-pkg script Yann E. MORIN
@ 2017-02-15 21:44 ` Yann E. MORIN
2017-02-15 21:44 ` [Buildroot] [PATCH 3/7 v4] support/test-pkg: print number of toolchain and progress Yann E. MORIN
` (5 subsequent siblings)
7 siblings, 0 replies; 15+ messages in thread
From: Yann E. MORIN @ 2017-02-15 21:44 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply related [flat|nested] 15+ messages in thread* [Buildroot] [PATCH 3/7 v4] support/test-pkg: print number of toolchain and progress
2017-02-15 21:44 [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements Yann E. MORIN
2017-02-15 21:44 ` [Buildroot] [PATCH 1/7 v4] docs/manual: document the test-pkg script Yann E. MORIN
2017-02-15 21:44 ` [Buildroot] [PATCH 2/7 v4] support/test-pkg: add option to use an alternate list of toolchains Yann E. MORIN
@ 2017-02-15 21:44 ` Yann E. MORIN
2017-02-15 21:44 ` [Buildroot] [PATCH 4/7 v4] support/test-pkg: the list of toolchains really contains URLs Yann E. MORIN
` (4 subsequent siblings)
7 siblings, 0 replies; 15+ messages in thread
From: Yann E. MORIN @ 2017-02-15 21:44 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply related [flat|nested] 15+ messages in thread* [Buildroot] [PATCH 4/7 v4] support/test-pkg: the list of toolchains really contains URLs
2017-02-15 21:44 [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements Yann E. MORIN
` (2 preceding siblings ...)
2017-02-15 21:44 ` [Buildroot] [PATCH 3/7 v4] support/test-pkg: print number of toolchain and progress Yann E. MORIN
@ 2017-02-15 21:44 ` Yann E. MORIN
2017-02-15 21:44 ` [Buildroot] [PATCH 5/7 v4] support/test-pkg: cannonicalize paths early Yann E. MORIN
` (3 subsequent siblings)
7 siblings, 0 replies; 15+ messages in thread
From: Yann E. MORIN @ 2017-02-15 21:44 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply related [flat|nested] 15+ messages in thread* [Buildroot] [PATCH 5/7 v4] support/test-pkg: cannonicalize paths early
2017-02-15 21:44 [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements Yann E. MORIN
` (3 preceding siblings ...)
2017-02-15 21:44 ` [Buildroot] [PATCH 4/7 v4] support/test-pkg: the list of toolchains really contains URLs Yann E. MORIN
@ 2017-02-15 21:44 ` Yann E. MORIN
2017-02-15 21:44 ` [Buildroot] [PATCH 6/7 v4] support/test-pkg: create build dir from caller Yann E. MORIN
` (2 subsequent siblings)
7 siblings, 0 replies; 15+ messages in thread
From: Yann E. MORIN @ 2017-02-15 21:44 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply related [flat|nested] 15+ messages in thread* [Buildroot] [PATCH 6/7 v4] support/test-pkg: create build dir from caller
2017-02-15 21:44 [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements Yann E. MORIN
` (4 preceding siblings ...)
2017-02-15 21:44 ` [Buildroot] [PATCH 5/7 v4] support/test-pkg: cannonicalize paths early Yann E. MORIN
@ 2017-02-15 21:44 ` Yann E. MORIN
2017-02-15 21:44 ` [Buildroot] [PATCH 7/7 v4] support/test-pkg: run legal-info Yann E. MORIN
2017-04-05 14:37 ` [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements Arnout Vandecappelle
7 siblings, 0 replies; 15+ messages in thread
From: Yann E. MORIN @ 2017-02-15 21:44 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply related [flat|nested] 15+ messages in thread* [Buildroot] [PATCH 7/7 v4] support/test-pkg: run legal-info
2017-02-15 21:44 [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements Yann E. MORIN
` (5 preceding siblings ...)
2017-02-15 21:44 ` [Buildroot] [PATCH 6/7 v4] support/test-pkg: create build dir from caller Yann E. MORIN
@ 2017-02-15 21:44 ` Yann E. MORIN
2017-04-05 14:37 ` [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements Arnout Vandecappelle
7 siblings, 0 replies; 15+ messages in thread
From: Yann E. MORIN @ 2017-02-15 21:44 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply related [flat|nested] 15+ messages in thread* [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements
2017-02-15 21:44 [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements Yann E. MORIN
` (6 preceding siblings ...)
2017-02-15 21:44 ` [Buildroot] [PATCH 7/7 v4] support/test-pkg: run legal-info Yann E. MORIN
@ 2017-04-05 14:37 ` Arnout Vandecappelle
2017-04-05 19:16 ` Yann E. MORIN
7 siblings, 1 reply; 15+ messages in thread
From: Arnout Vandecappelle @ 2017-04-05 14:37 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements
2017-04-05 14:37 ` [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements Arnout Vandecappelle
@ 2017-04-05 19:16 ` Yann E. MORIN
2017-04-06 8:48 ` Arnout Vandecappelle
0 siblings, 1 reply; 15+ messages in thread
From: Yann E. MORIN @ 2017-04-05 19:16 UTC (permalink / raw)
To: buildroot
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. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements
2017-04-05 19:16 ` Yann E. MORIN
@ 2017-04-06 8:48 ` Arnout Vandecappelle
2017-04-06 15:55 ` Yann E. MORIN
0 siblings, 1 reply; 15+ messages in thread
From: Arnout Vandecappelle @ 2017-04-06 8:48 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements
2017-04-06 8:48 ` Arnout Vandecappelle
@ 2017-04-06 15:55 ` Yann E. MORIN
2017-04-06 17:19 ` Arnout Vandecappelle
0 siblings, 1 reply; 15+ messages in thread
From: Yann E. MORIN @ 2017-04-06 15:55 UTC (permalink / raw)
To: buildroot
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. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] [PATCH 0/7 v4] support/test-pkg: fixes and enhancements
2017-04-06 15:55 ` Yann E. MORIN
@ 2017-04-06 17:19 ` Arnout Vandecappelle
0 siblings, 0 replies; 15+ messages in thread
From: Arnout Vandecappelle @ 2017-04-06 17:19 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 15+ messages in thread