tools: add a directory to contain usefull user-facing tools
v2 cover tools: add a directory to contain usefull user-facing tools
Hello All!
Currently, we provide a few user-facing utilities, like get-developers, in support/scripts/ . But this directory also contains internal scripts that a user should not be directly concerned with. Besides, it is two-level deep in the hierarchy, which is not really nice.
So, we introduce tools/ as a top-level directory, with the goal to store and expose all user-facing utilities, while keeping our internal scripts in support/scripts/ .
The first patch in the series introduces a new utility, brmake, a wrapper around make that stores all the output to a log file and displays only the >>> lines.
The second and subsequent patches each move a few user-facing utilities out of support/scripts/ and into tools/ .
Changes v1 -> v2:
- rename contrib -> tools (Arnout)
- move more scripts
Regards,
Yann E. MORIN.
The following changes since commit 859764ac39c18c6aaabbb6a1a47f2fa2e5793044
linux-headers: bump 4.{1, 4, 9, 11}.x series (2017-06-17 16:17:04 +0200)
are available in the git repository at:
git://git.buildroot.org/~ymorin/git/buildroot.git
for you to fetch changes up to eb8cb9682d84d1f110044a1448f18ef95ad79e84
tools: move check-package out of support/scripts/ (2017-06-17 21:09:20 +0200)
----------------------------------------------------------------
Yann E. MORIN (4):
tools: add a directory to store some useful user-facing tools
tools: move test-pkg out of support/scripts
tools: move get-developers out of support/scripts/
tools: move check-package out of support/scripts/
docs/manual/adding-packages-tips.txt | 12 +-
docs/manual/contribute.txt | 2 +-
docs/manual/writing-rules.txt | 5 +-
support/scripts/check-package | 145 +--------------
support/scripts/get-developers | 84 +--------
support/scripts/pkg-stats | 2 +-
support/scripts/test-pkg | 198 +--------------------
tools/00-README.txt | 23 +++
tools/brmake | 37 ++++
{support/scripts => tools}/check-package | 2 +-
.../scripts => tools}/checkpackagelib/__init__.py | 0
{support/scripts => tools}/checkpackagelib/base.py | 0
{support/scripts => tools}/checkpackagelib/lib.py | 0
.../checkpackagelib/lib_config.py | 0
.../scripts => tools}/checkpackagelib/lib_hash.py | 0
.../scripts => tools}/checkpackagelib/lib_mk.py | 0
.../scripts => tools}/checkpackagelib/lib_patch.py | 0
.../scripts => tools}/checkpackagelib/readme.txt | 10 +-
{support/scripts => tools}/get-developers | 0
{support/scripts => tools}/getdeveloperlib.py | 0
{support/scripts => tools}/test-pkg | 0
21 files changed, 80 insertions(+), 440 deletions(-)
mode change 100755 => 120000 support/scripts/check-package
mode change 100755 => 120000 support/scripts/get-developers
mode change 100755 => 120000 support/scripts/test-pkg
create mode 100644 tools/00-README.txt
create mode 100755 tools/brmake
copy {support/scripts => tools}/check-package (98%)
rename {support/scripts => tools}/checkpackagelib/__init__.py (100%)
rename {support/scripts => tools}/checkpackagelib/base.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_config.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_hash.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_mk.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_patch.py (100%)
rename {support/scripts => tools}/checkpackagelib/readme.txt (91%)
copy {support/scripts => tools}/get-developers (100%)
rename {support/scripts => tools}/getdeveloperlib.py (100%)
copy {support/scripts => tools}/test-pkg (100%)Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH v2 1/4 tools: add a directory to store some useful user-facing tools
Add a tools directory to store useful little scripts, tools, etc... Users may add that directory in their PATH if they want to, but this is not mandatory.
Add the first tool: brmake, a small script that redirects the build output log to a file, keeping just Buildroot's own messages, with the date+time added at the start of the line.
We need to unbuffer the output of make so that, when the script is interrupted (SIGINT, ^C), there is no lingering output not yet digested by the logger loop.
---
Changes v1 -> v2:
- rename contrib -> tools (Arnout)
- detect missing unbuffer (Arnout)
Notes:
- Arnout suggested using 'stdbuf' instead of 'unbuffer', but that has some shortcomings in weird corner-cases because it uses LD_PRELOAD to call a constructor that forces settings on stdout/stderr/stdin (it cost me three days to investigate a build failure because of that). So, I stuck with 'unbuffer'...
- I also tried to use bash' coproc, but it seems there was a regression in later bash versions that causes an incorrect redirect. So, I stuck with 'unbuffer'...
--- docs/manual/writing-rules.txt | 5 +++-- tools/00-README.txt | 9 +++++++++ tools/brmake | 37 +++++++++++++++++++++++++++++++++++++ 3 files changed, 49 insertions(+), 2 deletions(-) create mode 100644 tools/00-README.txt create mode 100755 tools/brmake
docs/manual/writing-rules.txt +3 -2
@@ -146,5 +146,6 @@ syntax, refer to http://www.methods.co.nz/asciidoc/userguide.html[]. === Support scripts -Some scripts in the +support/+ directory are written in Python and should follow -the https://www.python.org/dev/peps/pep-0008/[PEP8 Style Guide for Python Code]. +Some scripts in the +support/+ and +tools/+ directories are written in +Python and should follow the +https://www.python.org/dev/peps/pep-0008/[PEP8 Style Guide for Python Code].
tools/00-README.txt new file +9 -0
@@ -0,0 +1,9 @@ +This directory contains various useful scripts and tools for working +with Buildroot. You need not add this directory in your PATH to use +any of those tools, but you may do so if you want. + +brmake + a script that can be run instead of make, that prepends the date in + front of each line, redirects all of the build output to a file + ("'br.log' in the current directory), and just ouputs the Buildroot + messages (those lines starting with >>>) on stdout.
tools/brmake new file +37 -0
@@ -0,0 +1,37 @@ +#!/bin/bash +# (C) 2016, "Yann E. MORIN" <[email protected]> +# License: WTFPL, https://spdx.org/licenses/WTFPL.html + +main() { + local ret start d h m mf fs + + if ! which unbuffer >/dev/null 2>&1; then + printf "you need to install 'unbuffer' (from package expect or expect-dev)\n" >&2 + exit 1 + fi + + start=${SECONDS} + + ( exec 2>&1; unbuffer make "${@}"; ) \ + > >( while read line; do + printf "%(%Y-%m-%dT%H:%M:%S)T %s\n" -1 "${line}" + done \ + |tee -a br.log \ + |grep --colour=never -E '>>>' + ) + ret=${?} + + d=$((SECONDS-start)) + printf "Done in " + h=$((d/3600)) + d=$((d%3600)) + [ ${h} -eq 0 ] || { printf "%dh " ${h}; mf="02"; } + m=$((d/60)) + d=$((d%60)) + [ ${m} -eq 0 ] || { printf "%${mf}dmin " ${m}; sf="02"; } + printf "%${sf}ds\n" ${d} + + return ${ret} +} + +main "${@}"
Signature · 1 line
2.11.0
PATCH v2 1/4 tools: add a directory to store some useful user-facing tools
Hello,
Quoted 8 lines · Yann E. MORIN
Add a tools directory to store useful little scripts, tools, etc... Users may add that directory in their PATH if they want to, but this is not mandatory.
Add the first tool: brmake, a small script that redirects the build output log to a file, keeping just Buildroot's own messages, with the date+time added at the start of the line.
Quoted 7 lines
We need to unbuffer the output of make so that, when the script is interrupted (SIGINT, ^C), there is no lingering output not yet digested by the logger loop.
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Maxime Hadjinlian <[email protected]>Cc Arnout Vandecappelle <[email protected]>
I tested the script and it works very well in general.
- I successfully built the qemu_arm_versatile_defconfig using the script, pressing CTRL+C a few times and resuming by calling it again.
- Also, by inserting an error to a package I got the expected behaviour: the error message is in the log file and the script returned the error code.
- Tested using 'GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)'
BUT if it is called without a .config file, it hangs forever waiting for input, and the menuconfig is sent to the log file.
Maybe we can bailout if no .config is present.
Also, 2 small nits below.
tools/00-README.txt line 8
Quoted 10 lines
+++
b/tools/00-README.txttools/00-README.txt new file +8
-0@@ -0,0 +1,9 @@ +This directory contains various useful scripts and tools for working +with Buildroot. You need not add this directory in your PATH to use +any of those tools, but you may do so if you want. + +brmake + a script that can be run instead of make, that prepends the date in + front of each line, redirects all of the build output to a file + ("'br.log' in the current directory), and just ouputs the Buildroot
Maybe this file will be dropped as discussed in
http://patchwork.ozlabs.org/patch/777446/
If not, there is a typo
ouputs -> outputs
tools/brmake line 6
Quoted 13 lines
tools/00-README.txt new file +1
-0+ messages (those lines starting with >>>) on stdout.tools/brmake new file +6
-0@@ -0,0 +1,37 @@ +#!/bin/bash +# (C) 2016, "Yann E. MORIN" <[email protected]> +# License: WTFPL, https://spdx.org/licenses/WTFPL.html + +main() { + local ret start d h m mf fs
fs is unused.
Regards,
Ricardo
PATCH v2 1/4 tools: add a directory to store some useful user-facing tools
Ricardo, All,
On 2017-06-18 22:11 -0300, Ricardo Martincoski spake thusly:
Quoted 19 lines · Yann E. MORIN
Quoted 8 lines
Add a tools directory to store useful little scripts, tools, etc... Users may add that directory in their PATH if they want to, but this is not mandatory.
Add the first tool: brmake, a small script that redirects the build output log to a file, keeping just Buildroot's own messages, with the date+time added at the start of the line.
Quoted 7 lines
We need to unbuffer the output of make so that, when the script is interrupted (SIGINT, ^C), there is no lingering output not yet digested by the logger loop.
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Maxime Hadjinlian <[email protected]>Cc Arnout Vandecappelle <[email protected]>I tested the script and it works very well in general.
Quoted 8 lines
- I successfully built the
qemu_arm_versatile_defconfigusing the script, pressing CTRL+C a few times and resuming by calling it again.
- Also, by inserting an error to a package I got the expected behaviour: the error message is in the log file and the script returned the error code.
- Tested using 'GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)'BUT if it is called without a .config file, it hangs forever waiting for input, and the menuconfig is sent to the log file.
Indeed, my use-case is to only use it in an already-configured tree.
Quoted 1 line
Maybe we can bailout if no .config is present.
Hmmm... It's not trivial do detect, because the .config file is not necessarily in the current directory, for example:
brmake -C /pat/to/buil-dir
and I don't want to write a make option interpeter either...
But I'll see what I can do.
Quoted 17 lines
Also, 2 small nits below.
tools/00-README.txt line 8
Quoted 10 lines
+++
b/tools/00-README.txttools/00-README.txt new file +8
-0@@ -0,0 +1,9 @@ +This directory contains various useful scripts and tools for working +with Buildroot. You need not add this directory in your PATH to use +any of those tools, but you may do so if you want. + +brmake + a script that can be run instead of make, that prepends the date in + front of each line, redirects all of the build output to a file + ("'br.log' in the current directory), and just ouputs the BuildrootMaybe this file will be dropped as discussed in
http://patchwork.ozlabs.org/patch/777446/
If not, there is a typo
Quoted 1 line
ouputs -> outputs
Yup, I already dropped the file locally.
Quoted 7 lines
Quoted 7 lines
tools/00-README.txt new file +1
-0+ messages (those lines starting with >>>) on stdout.tools/brmake new file +0
-0@@ -0,0 +1,37 @@
Quoted 8 lines
tools/brmake line 6
Quoted 6 lines
tools/brmake new file +6
-0+#!/bin/bash +# (C) 2016, "Yann E. MORIN" <[email protected]> +# License: WTFPL, https://spdx.org/licenses/WTFPL.html + +main() { + local ret start d h m mf fsfs is unused.
OK. Thanks for the review and tests! :-)
Regards,
Yann E. MORIN.
Quoted 2 lines
Regards,
Ricardo
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH v2 1/4 tools: add a directory to store some useful user-facing tools
Hello,
Quoted 1 line · Yann E. MORIN
On 2017-06-18 22:11 -0300, Ricardo Martincoski spake thusly:
[snip]
Quoted 5 lines
Quoted 2 lines
BUT if it is called without a .config file, it hangs forever waiting for input, and the menuconfig is sent to the log file.
Indeed, my use-case is to only use it in an already-configured tree.
Quoted 8 lines
Quoted 1 line
Maybe we can bailout if no .config is present.
Hmmm... It's not trivial do detect, because the .config file is not necessarily in the current directory, for example:
brmake -C /pat/to/buil-dir
and I don't want to write a make option interpeter either...
Oh, I see now it is not trivial.
Quoted 2 lines
But I'll see what I can do.
Only on the first use the user can get confused.
I think adding a usage example in the file header is enough, saying the script must be run inside or pointing to (-C from make) an output directory already configured, or something like that.
[snip]
Quoted 11 lines
Quoted 9 lines
tools/00-README.txt line 8
Quoted 3 lines
tools/00-README.txt new file +3
-0+ a script that can be run instead of make, that prepends the date in + front of each line, redirects all of the build output to a file + ("'br.log' in the current directory), and just ouputs the BuildrootMaybe this file will be dropped as discussed in
http://patchwork.ozlabs.org/patch/777446/
If not, there is a typoouputs -> outputs
Yup, I already dropped the file locally.
[snip]
The purpose of the script (initially in 00-README.txt, with the typo fixed) could be placed in the script header as well.
Regards,
Ricardo
PATCH v2 1/4 tools: add a directory to store some useful user-facing tools
Ricardo, All,
On 2017-06-20 23:06 -0300, Ricardo Martincoski spake thusly:
Quoted 10 lines · Yann E. MORIN
Quoted 1 line
On 2017-06-18 22:11 -0300, Ricardo Martincoski spake thusly:
[snip]
Quoted 7 lines
Quoted 2 lines
BUT if it is called without a .config file, it hangs forever waiting for input, and the menuconfig is sent to the log file.
Indeed, my use-case is to only use it in an already-configured tree.
Quoted 1 line
Maybe we can bailout if no .config is present.
Quoted 8 lines
Quoted 6 lines
Hmmm... It's not trivial do detect, because the .config file is not necessarily in the current directory, for example:
brmake -C /pat/to/buil-dir
and I don't want to write a make option interpeter either...
Oh, I see now it is not trivial.
Yet I think I was able to do it in a minimalist way that should cover 99.999999% of the cases (or so I hope, famous last words):
https://git.buildroot.org/~ymorin/git/buildroot/commit/?h=yem/contrib&id=221c72431bb12e0dde4051d9317d9fee2bee6eb2
I'll resubmit soon (after a bit more testing...)
Quoted 14 lines
Only on the first use the user can get confused.
I think adding a usage example in the file header is enough, saying the script must be run inside or pointing to (-C from make) an output directory already configured, or something like that.[snip]
Quoted 8 lines
Quoted 8 lines
tools/00-README.txt line 8
Quoted 3 lines
tools/00-README.txt new file +3
-0+ a script that can be run instead of make, that prepends the date in + front of each line, redirects all of the build output to a file + ("'br.log' in the current directory), and just ouputs the BuildrootMaybe this file will be dropped as discussed in
http://patchwork.ozlabs.org/patch/777446/
If not, there is a typo
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
ouputs -> outputs
Yup, I already dropped the file locally.
[snip]
The purpose of the script (initially in 00-README.txt, with the typo fixed) could be placed in the script header as well.
Yep, good idea. I'll do that.
Thanks!
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH v2 1/4 tools: add a directory to store some useful user-facing tools
Quoted 21 lines · Yann E. MORIN
Ricardo, All,
On 2017-06-20 23:06 -0300, Ricardo Martincoski spake thusly:
Quoted 18 lines · Yann E. MORIN
Quoted 1 line
On 2017-06-18 22:11 -0300, Ricardo Martincoski spake thusly:
[snip]
Quoted 5 lines
Quoted 2 lines
BUT if it is called without a .config file, it hangs forever waiting for input, and the menuconfig is sent to the log file.
Indeed, my use-case is to only use it in an already-configured tree.
Quoted 8 lines
Quoted 1 line
Maybe we can bailout if no .config is present.
Hmmm... It's not trivial do detect, because the .config file is not necessarily in the current directory, for example:
brmake -C /pat/to/buil-dir
and I don't want to write a make option interpeter either...
Oh, I see now it is not trivial.
How about instead make the script do
make -C ${0%/*}/.. O=${PWD} "${@}"
if $PWD is not the Buildroot dir. This still allows overriding either option on the command line.
Not that this solves the issue...
Quoted 3 lines
Yet I think I was able to do it in a minimalist way that should cover 99.999999% of the cases (or so I hope, famous last words):
https://git.buildroot.org/~ymorin/git/buildroot/commit/?h=yem/contrib&id=221c72431bb12e0dde4051d9317d9fee2bee6eb2
I haven't tried, but doesn't it do the wrong thing with
make O=... -C ...
?
But it still doesn't completely solve the issue, because "brmake menuconfig"
still does the wrong thing... Unfortunately I don't know how to solve that (other than detecting menuconfig as an argument, obviously).
On a related note, perhaps it's better to redirect stdin in case there is
something interactive during the build (e.g. Qt license approval).
Regards,
Arnout
Quoted 31 lines
I'll resubmit soon (after a bit more testing...)
Quoted 14 lines
Only on the first use the user can get confused.
I think adding a usage example in the file header is enough, saying the script must be run inside or pointing to (-C from make) an output directory already configured, or something like that.[snip]
Quoted 8 lines
Quoted 8 lines
tools/00-README.txt line 8
Quoted 3 lines
tools/00-README.txt new file +3
-0+ a script that can be run instead of make, that prepends the date in + front of each line, redirects all of the build output to a file + ("'br.log' in the current directory), and just ouputs the BuildrootMaybe this file will be dropped as discussed in
http://patchwork.ozlabs.org/patch/777446/
If not, there is a typoQuoted 7 lines
Quoted 3 lines
Quoted 1 line
ouputs -> outputs
Yup, I already dropped the file locally.
[snip]
The purpose of the script (initially in 00-README.txt, with the typo fixed) could be placed in the script header as well.
Yep, good idea. I'll do that.
Thanks!
Regards,
Yann E. MORIN.
Signature · 6 lines
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
PATCH v2 1/4 tools: add a directory to store some useful user-facing tools
Arnout, All,
On 2017-06-21 23:44 +0200, Arnout Vandecappelle spake thusly:
Quoted 19 lines · Yann E. MORIN
Quoted 18 lines
Ricardo, All,
On 2017-06-20 23:06 -0300, Ricardo Martincoski spake thusly:
Quoted 15 lines · Yann E. MORIN
Quoted 1 line
On 2017-06-18 22:11 -0300, Ricardo Martincoski spake thusly:
[snip]
Quoted 12 lines
Quoted 2 lines
BUT if it is called without a .config file, it hangs forever waiting for input, and the menuconfig is sent to the log file.
Indeed, my use-case is to only use it in an already-configured tree.
Quoted 1 line
Maybe we can bailout if no .config is present.
Hmmm... It's not trivial do detect, because the .config file is not necessarily in the current directory, for example:
brmake -C /pat/to/buil-dir
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
and I don't want to write a make option interpeter either...
Oh, I see now it is not trivial.
How about instead make the script do
make -C ${0%/*}/.. O=${PWD} "${@}"
What if one calls it with: brmake -C /path/to/my/O-dir
But as much as we try to 'fix' it, we always uncover corner cases, becausze the above would consider ${PWD} to be the output dir if /path/to/my/O-dir is not already configured... :-/
Corner cases after corner cases, I think I'd just try to catch the obvious and trivial, and leave out the weird cases.
So, either there is a .config in the CWD, or we abort. Deal? ;-)
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH v2 2/4 tools: move test-pkg out of support/scripts
In reply to Yann E. MORINMove it to the top-level tools/ directory, so that it is easier to find for users.
Add a legacy symlink for those users who already used them, so as not to break their habits.
--- docs/manual/adding-packages-tips.txt | 12 +-- support/scripts/test-pkg | 198 +---------------------------------- tools/00-README.txt | 5 + tools/test-pkg | 197 ++++++++++++++++++++++++++++++++++ 4 files changed, 209 insertions(+), 203 deletions(-) mode change 100755 => 120000 support/scripts/test-pkg create mode 100755 tools/test-pkg
docs/manual/adding-packages-tips.txt +6 -6
@@ -45,9 +45,9 @@ 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. +Buildroot provides a script in +tools/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 enable your package, but without any architecture or toolchain
@@ -74,7 +74,7 @@ Then run the +test-pkg+ script, by telling it what config snippet to use and what package to test: ---- -$ ./support/scripts/test-pkg -c libcurl.config -p libcurl +$ ./tools/test-pkg -c libcurl.config -p libcurl ---- This will try to build your package against all the toolchains used
@@ -83,7 +83,7 @@ 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 +$ ./tools/test-pkg -c libcurl.config -p libcurl armv5-ctng-linux-gnueabi [ 1/11]: OK armv7-ctng-linux-gnueabihf [ 2/11]: OK br-aarch64-glibc [ 3/11]: SKIPPED
@@ -124,7 +124,7 @@ The +test-pkg+ script accepts a few options, for which you can get some help by running: ---- -$ ./support/scripts/test-pkg -h +$ ./tools/test-pkg -h ---- [[github-download-url]]
support/scripts/test-pkg deleted +0 -197
197 lines not on this page · raw message
support/scripts/test-pkg new file +1 -0
@@ -0,0 +1 @@ +../../tools/test-pkg
tools/00-README.txt +5 -0
@@ -7,3 +7,8 @@ brmake front of each line, redirects all of the build output to a file ("'br.log' in the current directory), and just ouputs the Buildroot messages (those lines starting with >>>) on stdout. + +test-pkg + a script that tests a specific package against a set of various + toolchains, with the goal to detect toolchain-related dependencies + (wchar, threads...)
tools/test-pkg new file +197 -0
197 lines not on this page · raw message
Signature · 1 line
2.11.0
PATCH v2 2/4 tools: move test-pkg out of support/scripts
Hello,
Quoted 7 lines · Yann E. MORIN
docs/manual/adding-packages-tips.txt | 12 +-- support/scripts/test-pkg | 198 +---------------------------------- tools/00-README.txt | 5 + tools/test-pkg | 197 ++++++++++++++++++++++++++++++++++ 4 files changed, 209 insertions(+), 203 deletions(-) mode change 100755 => 120000 support/scripts/test-pkg create mode 100755 tools/test-pkg
No strong opinion on whether such a move is desirable, but at the very list I believe we should not add this 00-README.txt file. Nowhere else in the tree we have files named like this, and I don't think we should start adding these.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH v2 2/4 tools: move test-pkg out of support/scripts
Thomas, All,
On 2017-06-18 16:12 +0200, Thomas Petazzoni spake thusly:
Quoted 10 lines · Yann E. MORIN
Quoted 7 lines
docs/manual/adding-packages-tips.txt | 12 +-- support/scripts/test-pkg | 198 +---------------------------------- tools/00-README.txt | 5 + tools/test-pkg | 197 ++++++++++++++++++++++++++++++++++ 4 files changed, 209 insertions(+), 203 deletions(-) mode change 100755 => 120000 support/scripts/test-pkg create mode 100755 tools/test-pkgNo strong opinion on whether such a move is desirable,
That was a proposal by Arnout:
http://lists.busybox.net/pipermail/buildroot/2016-October/174290.html
Quoted 4 lines
but at the very
list I believe we should not add this 00-README.txt file. Nowhere else in the tree we have files named like this, and I don't think we should start adding these.
I'm OK for dropping it.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH v2 2/4 tools: move test-pkg out of support/scripts
In reply to Thomas PetazzoniQuoted 12 lines · Thomas Petazzoni
Hello,
Quoted 7 lines · Yann E. MORIN
docs/manual/adding-packages-tips.txt | 12 +-- support/scripts/test-pkg | 198 +---------------------------------- tools/00-README.txt | 5 + tools/test-pkg | 197 ++++++++++++++++++++++++++++++++++ 4 files changed, 209 insertions(+), 203 deletions(-) mode change 100755 => 120000 support/scripts/test-pkg create mode 100755 tools/test-pkg
Quoted 4 lines
No strong opinion on whether such a move is desirable, but at the very list I believe we should not add this 00-README.txt file. Nowhere else in the tree we have files named like this, and I don't think we should start adding these.
Well, we have readme.txt in boards/, we have a README at the top level, we have
a README generated by legal-info, we have a readme.txt in checkpackagelib... We indeed don't have a 00-README.txt though. IMO all of these files should be called README.md (or readme.md) so they are nicely formatted when viewed online.
For this particular instance, I do like having some kind of README there. We
need an overview of the existing tools somewhere, and I think a README file is a more appropriate place than the manual because it's easier to keep consistent. From the manual you can point to the directory.
Regards,
Arnout
Signature · 6 lines
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
PATCH v2 2/4 tools: move test-pkg out of support/scripts
Hello,
Quoted 10 lines · Arnout Vandecappelle
Quoted 4 lines
No strong opinion on whether such a move is desirable, but at the very list I believe we should not add this 00-README.txt file. Nowhere else in the tree we have files named like this, and I don't think we should start adding these.
Well, we have readme.txt in boards/, we have a README at the top level, we have
a README generated by legal-info, we have a readme.txt in checkpackagelib... We indeed don't have a 00-README.txt though. IMO all of these files should be called README.md (or readme.md) so they are nicely formatted when viewed online.
Quoted 4 lines
For this particular instance, I do like having some kind of README there. We
need an overview of the existing tools somewhere, and I think a README file is a more appropriate place than the manual because it's easier to keep consistent. From the manual you can point to the directory.
ACK, but then, named "readme.txt", to match what we're doing elsewhere:
$ find . -name 'readme.txt' | wc -l 99
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH v2 2/4 tools: move test-pkg out of support/scripts
Quoted 19 lines · Thomas Petazzoni
Hello,
Quoted 10 lines · Arnout Vandecappelle
Quoted 4 lines
No strong opinion on whether such a move is desirable, but at the very list I believe we should not add this 00-README.txt file. Nowhere else in the tree we have files named like this, and I don't think we should start adding these.
Well, we have readme.txt in boards/, we have a README at the top level, we have
a README generated by legal-info, we have a readme.txt in checkpackagelib... We indeed don't have a 00-README.txt though. IMO all of these files should be called README.md (or readme.md) so they are nicely formatted when viewed online.Quoted 4 lines
For this particular instance, I do like having some kind of README there. We
need an overview of the existing tools somewhere, and I think a README file is a more appropriate place than the manual because it's easier to keep consistent. From the manual you can point to the directory.
Quoted 4 lines
ACK, but then, named "readme.txt", to match what we're doing elsewhere:
$ find . -name 'readme.txt' | wc -l 99
Well, the point I tried to make in the paragraph above is that readme.txt is
not a great name, readme.md would be better so it gets nicely formatted when viewed online on github, gitlab, etc and also in some editors. README.md is even better because then it is sorted first - which for the tools directory is very relevant IMO.
Note that 96 of those 99 readmes are in board/. But they still should be called
readme.md :-)
Regards,
Arnout
Signature · 6 lines
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
PATCH v2 2/4 tools: move test-pkg out of support/scripts
Arnout, Thomas, All,
On 2017-06-22 10:30 +0200, Arnout Vandecappelle spake thusly:
Quoted 20 lines · Thomas Petazzoni
Quoted 19 lines
Hello,
Quoted 14 lines · Arnout Vandecappelle
Quoted 4 lines
No strong opinion on whether such a move is desirable, but at the very list I believe we should not add this 00-README.txt file. Nowhere else in the tree we have files named like this, and I don't think we should start adding these.
Well, we have readme.txt in boards/, we have a README at the top level, we have
a README generated by legal-info, we have a readme.txt in checkpackagelib... We indeed don't have a 00-README.txt though. IMO all of these files should be called README.md (or readme.md) so they are nicely formatted when viewed online.For this particular instance, I do like having some kind of README there. We
need an overview of the existing tools somewhere, and I think a README file is a more appropriate place than the manual because it's easier to keep consistent. From the manual you can point to the directory.
Quoted 4 lines
Quoted 4 lines
ACK, but then, named "readme.txt", to match what we're doing elsewhere:
$ find . -name 'readme.txt' | wc -l 99
OK, I'll re-instate the readme, and will change its name to readme.txt.
Quoted 8 lines
Well, the point I tried to make in the paragraph above is that readme.txt is
not a great name, readme.md would be better so it gets nicely formatted when viewed online on github, gitlab, etc and also in some editors. README.md is even better because then it is sorted first - which for the tools directory is very relevant IMO.Note that 96 of those 99 readmes are in board/. But they still should be called
readme.md :-)
IIUC, github et al. expect README.md to contain Markdown, not plain text. A simple README (or maybe readme as well) would still be displayed, but no rednering would be done.
In any case, this is a topic for a completely different series.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH v2 3/4 tools: move get-developers out of support/scripts/
In reply to Yann E. MORINMove it to the top-level tools/ directory, so that it is easier to find for users.
Add a legacy symlink for those users who already used them, so as not to break their habits.
---
docs/manual/contribute.txt | 2 +-
support/scripts/get-developers | 84 +--------------------------
tools/00-README.txt | 5 ++
tools/get-developers | 83 ++++++++++++++++++++++++++
{support/scripts => tools}/getdeveloperlib.py | 0
5 files changed, 90 insertions(+), 84 deletions(-)
mode change 100755 => 120000 support/scripts/get-developers
create mode 100755 tools/get-developers
rename {support/scripts => tools}/getdeveloperlib.py (100%)docs/manual/contribute.txt +1 -1
@@ -295,7 +295,7 @@ information). This tool reads your patches and outputs the appropriate +git send-email+ command to use: --------------------- -$ ./support/scripts/get-developers outgoing/* +$ ./tools/get-developers outgoing/* --------------------- Use the output of +get-developers+ to send your patches:
support/scripts/get-developers deleted +0 -83
83 lines not on this page · raw message
support/scripts/get-developers new file +1 -0
@@ -0,0 +1 @@ +../../tools/get-developers
tools/00-README.txt +5 -0
@@ -8,6 +8,11 @@ brmake ("'br.log' in the current directory), and just ouputs the Buildroot messages (those lines starting with >>>) on stdout. +get-developpers + a script to return the list of people interested in a specific part + of Buildroot, so they can be Cc:ed on a mail. Accepts a patch as + input, a package name or and architecture name. + test-pkg a script that tests a specific package against a set of various toolchains, with the goal to detect toolchain-related dependencies
tools/get-developers new file +83 -0
83 lines not on this page · raw message
tools/getdeveloperlib.py renamed from support/scripts/getdeveloperlib.py +0 -0
Signature · 1 line
2.11.0
PATCH v2 4/4 tools: move check-package out of support/scripts/
In reply to Yann E. MORINMove it to the top-level tools/ directory, so that it is easier to find for users.
Add a legacy symlink for those users who already used them, so as not to break their habits.
---
support/scripts/check-package | 145 +--------------------
support/scripts/pkg-stats | 2 +-
tools/00-README.txt | 4 +
tools/check-package | 144 ++++++++++++++++++++
.../scripts => tools}/checkpackagelib/__init__.py | 0
{support/scripts => tools}/checkpackagelib/base.py | 0
{support/scripts => tools}/checkpackagelib/lib.py | 0
.../checkpackagelib/lib_config.py | 0
.../scripts => tools}/checkpackagelib/lib_hash.py | 0
.../scripts => tools}/checkpackagelib/lib_mk.py | 0
.../scripts => tools}/checkpackagelib/lib_patch.py | 0
.../scripts => tools}/checkpackagelib/readme.txt | 10 +-
12 files changed, 155 insertions(+), 150 deletions(-)
mode change 100755 => 120000 support/scripts/check-package
create mode 100755 tools/check-package
rename {support/scripts => tools}/checkpackagelib/__init__.py (100%)
rename {support/scripts => tools}/checkpackagelib/base.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_config.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_hash.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_mk.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_patch.py (100%)
rename {support/scripts => tools}/checkpackagelib/readme.txt (91%)support/scripts/check-package deleted +0 -144
@@ -1,144 +0,0 @@ -#!/usr/bin/env python -# See support/scripts/checkpackagelib/readme.txt before editing this file. - -from __future__ import print_function -import argparse -import inspect -import re -import sys - -import checkpackagelib.lib_config -import checkpackagelib.lib_hash -import checkpackagelib.lib_mk -import checkpackagelib.lib_patch - -VERBOSE_LEVEL_TO_SHOW_IGNORED_FILES = 3 -flags = None # Command line arguments. - - -def parse_args(): - parser = argparse.ArgumentParser() - - # Do not use argparse.FileType("r") here because only files with known - # format will be open based on the filename. - parser.add_argument("files", metavar="F", type=str, nargs="*", - help="list of files") - - parser.add_argument("--manual-url", action="store", - default="http://nightly.buildroot.org/", - help="default: %(default)s") - parser.add_argument("--verbose", "-v", action="count", default=0) - - # Now the debug options in the order they are processed. - parser.add_argument("--include-only", dest="include_list", action="append", - help="run only the specified functions (debug)") - parser.add_argument("--exclude", dest="exclude_list", action="append", - help="do not run the specified functions (debug)") - parser.add_argument("--dry-run", action="store_true", help="print the " - "functions that would be called for each file (debug)") - - return parser.parse_args() - - -CONFIG_IN_FILENAME = re.compile("/Config\.\S*$") -FILE_IS_FROM_A_PACKAGE = re.compile("package/[^/]*/") - - -def get_lib_from_filename(fname): - if FILE_IS_FROM_A_PACKAGE.search(fname) is None: - return None - if CONFIG_IN_FILENAME.search(fname): - return checkpackagelib.lib_config - if fname.endswith(".hash"): - return checkpackagelib.lib_hash - if fname.endswith(".mk"): - return checkpackagelib.lib_mk - if fname.endswith(".patch"): - return checkpackagelib.lib_patch - return None - - -def is_a_check_function(m): - if not inspect.isclass(m): - return False - # do not call the base class - if m.__name__.startswith("_"): - return False - if flags.include_list and m.__name__ not in flags.include_list: - return False - if flags.exclude_list and m.__name__ in flags.exclude_list: - return False - return True - - -def print_warnings(warnings): - # Avoid the need to use 'return []' at the end of every check function. - if warnings is None: - return 0 # No warning generated. - - for level, message in enumerate(warnings): - if flags.verbose >= level: - print(message.replace("\t", "< tab >").rstrip()) - return 1 # One more warning to count. - - -def check_file_using_lib(fname): - # Count number of warnings generated and lines processed. - nwarnings = 0 - nlines = 0 - - lib = get_lib_from_filename(fname) - if not lib: - if flags.verbose >= VERBOSE_LEVEL_TO_SHOW_IGNORED_FILES: - print("{}: ignored".format(fname)) - return nwarnings, nlines - classes = inspect.getmembers(lib, is_a_check_function) - - if flags.dry_run: - functions_to_run = [c[0] for c in classes] - print("{}: would run: {}".format(fname, functions_to_run)) - return nwarnings, nlines - - objects = [c[1](fname, flags.manual_url) for c in classes] - - for cf in objects: - nwarnings += print_warnings(cf.before()) - for lineno, text in enumerate(open(fname, "r").readlines()): - nlines += 1 - for cf in objects: - nwarnings += print_warnings(cf.check_line(lineno + 1, text)) - for cf in objects: - nwarnings += print_warnings(cf.after()) - - return nwarnings, nlines - - -def __main__(): - global flags - flags = parse_args() - - if len(flags.files) == 0: - print("No files to check style") - sys.exit(1) - - # Accumulate number of warnings generated and lines processed. - total_warnings = 0 - total_lines = 0 - - for fname in flags.files: - nwarnings, nlines = check_file_using_lib(fname) - total_warnings += nwarnings - total_lines += nlines - - # The warning messages are printed to stdout and can be post-processed - # (e.g. counted by 'wc'), so for stats use stderr. Wait all warnings are - # printed, for the case there are many of them, before printing stats. - sys.stdout.flush() - print("{} lines processed".format(total_lines), file=sys.stderr) - print("{} warnings generated".format(total_warnings), file=sys.stderr) - - if total_warnings > 0: - sys.exit(1) - - -__main__()
support/scripts/check-package new file +1 -0
@@ -0,0 +1 @@ +../../tools/check-package
support/scripts/pkg-stats +1 -1
@@ -337,7 +337,7 @@ for i in $(find boot/ linux/ package/ toolchain/ -name '*.mk' | sort) ; do fi file_list=$(find ${package_dir} -name '*.mk' -o -name '*.in*' -o -name '*.hash') - nwarnings=$(./support/scripts/check-package ${file_list} 2>&1 | sed '/\([0-9]*\) warnings generated/!d; s//\1/') + nwarnings=$(./tools/check-package ${file_list} 2>&1 | sed '/\([0-9]*\) warnings generated/!d; s//\1/') if [ ${nwarnings} -eq 0 ] ; then echo "<td class=\"centered correct\">${nwarnings}</td>" else
tools/00-README.txt +4 -0
@@ -8,6 +8,10 @@ brmake ("'br.log' in the current directory), and just ouputs the Buildroot messages (those lines starting with >>>) on stdout. +check-package + a script that checks the coding style of a package's Config.in and + .mk files, and also tests them for various types of typoes. + get-developpers a script to return the list of people interested in a specific part of Buildroot, so they can be Cc:ed on a mail. Accepts a patch as
tools/check-package new file +144 -0
144 lines not on this page · raw message
tools/checkpackagelib/__init__.py renamed from support/scripts/checkpackagelib/__init__.py +0 -0
tools/checkpackagelib/base.py renamed from support/scripts/checkpackagelib/base.py +0 -0
tools/checkpackagelib/lib.py renamed from support/scripts/checkpackagelib/lib.py +0 -0
tools/checkpackagelib/lib_config.py renamed from support/scripts/checkpackagelib/lib_config.py +0 -0
tools/checkpackagelib/lib_hash.py renamed from support/scripts/checkpackagelib/lib_hash.py +0 -0
tools/checkpackagelib/lib_mk.py renamed from support/scripts/checkpackagelib/lib_mk.py +0 -0
tools/checkpackagelib/lib_patch.py renamed from support/scripts/checkpackagelib/lib_patch.py +0 -0
tools/checkpackagelib/readme.txt renamed from support/scripts/checkpackagelib/readme.txt +5 -5
@@ -57,19 +57,19 @@ Some hints when changing this code: Usage examples: - to get a list of check functions that would be called without actually calling them you can use the --dry-run option: -$ support/scripts/check-package --dry-run package/yourfavorite/* +$ tools/check-package --dry-run package/yourfavorite/* - when you just added a new check function, e.g. Something, check how it behaves for all current packages: -$ support/scripts/check-package --include-only Something $(find package -type f) +$ tools/check-package --include-only Something $(find package -type f) - the effective processing time (when the .pyc were already generated and all files to be processed are cached in the RAM) should stay in the order of few seconds: -$ support/scripts/check-package $(find package -type f) >/dev/null ; \ - time support/scripts/check-package $(find package -type f) >/dev/null +$ tools/check-package $(find package -type f) >/dev/null ; \ + time tools/check-package $(find package -type f) >/dev/null - vim users can navigate the warnings (most editors probably have similar function) since warnings are generated in the form 'path/file:line: warning': $ find package/ -name 'Config.*' > filelist && vim -c \ - 'set makeprg=support/scripts/check-package\ $(cat\ filelist)' -c make -c copen + 'set makeprg=tools/check-package\ $(cat\ filelist)' -c make -c copen
Signature · 1 line
2.11.0
PATCH v2 4/4 tools: move check-package out of support/scripts/
Hello,
On Sun, Jun 18, 2017 at 11:01 AM, Yann E. MORIN wrote:
[snip]
Quoted 7 lines
rename {support/scripts => tools}/checkpackagelib/base.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_config.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_hash.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_mk.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_patch.py (100%)
rename {support/scripts => tools}/checkpackagelib/readme.txt (91%)nit: there are 6 more comments using the old path.
-# See support/scripts/checkpackagelib/readme.txt before editing this file. +# See tools/checkpackagelib/readme.txt before editing this file.
It could be fixed when applying using this sed:
sed -e 's,support/scripts/,tools/,g' -i tools/checkpackagelib/*.py
Another option is to remove the 6 comments if you think they are too repetitive.
Regards,
Ricardo
PATCH v2 4/4 tools: move check-package out of support/scripts/
Ricardo, All,
On 2017-06-18 22:13 -0300, Ricardo Martincoski spake thusly:
Quoted 11 lines · Yann E. MORIN
[snip]
Quoted 7 lines
rename {support/scripts => tools}/checkpackagelib/base.py (100%) rename {support/scripts => tools}/checkpackagelib/lib.py (100%) rename {support/scripts => tools}/checkpackagelib/lib_config.py (100%) rename {support/scripts => tools}/checkpackagelib/lib_hash.py (100%) rename {support/scripts => tools}/checkpackagelib/lib_mk.py (100%) rename {support/scripts => tools}/checkpackagelib/lib_patch.py (100%) rename {support/scripts => tools}/checkpackagelib/readme.txt (91%)nit: there are 6 more comments using the old path.
Damn, right.
Quoted 7 lines
(quoted diff) +1
-1-# See support/scripts/checkpackagelib/readme.txt before editing this file. +# See tools/checkpackagelib/readme.txt before editing this file.It could be fixed when applying using this sed:
sed -e 's,support/scripts/,tools/,g' -itools/checkpackagelib/*.pyAnother option is to remove the 6 comments if you think they are too repetitive.
Fixed.
Thanks for the review! :-)
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH v2 4/4 tools: move check-package out of support/scripts/
In reply to Yann E. MORINHello,
Quoted 16 lines · Yann E. MORIN
---
support/scripts/check-package | 145 +--------------------
support/scripts/pkg-stats | 2 +-
tools/00-README.txt | 4 +
tools/check-package | 144 ++++++++++++++++++++
.../scripts => tools}/checkpackagelib/__init__.py | 0
{support/scripts => tools}/checkpackagelib/base.py | 0
{support/scripts => tools}/checkpackagelib/lib.py | 0
.../checkpackagelib/lib_config.py | 0
.../scripts => tools}/checkpackagelib/lib_hash.py | 0
.../scripts => tools}/checkpackagelib/lib_mk.py | 0
.../scripts => tools}/checkpackagelib/lib_patch.py | 0
.../scripts => tools}/checkpackagelib/readme.txt | 10 +-
12 files changed, 155 insertions(+), 150 deletions(-)
mode change 100755 => 120000 support/scripts/check-package
create mode 100755 tools/check-packageQuoted 8 lines
rename {support/scripts => tools}/checkpackagelib/__init__.py (100%)
rename {support/scripts => tools}/checkpackagelib/base.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_config.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_hash.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_mk.py (100%)
rename {support/scripts => tools}/checkpackagelib/lib_patch.py (100%)
rename {support/scripts => tools}/checkpackagelib/readme.txt (91%)I forgot earlier...
Also the entry in the DEVELOPERS file must be updated
F: support/scripts/check*package*
Probably if I didn't used '*' it would be easier to find. I didn't tested but I assume we could use
F: tools/check-package
F: tools/checkpackagelib/
Regards,
Ricardo
PATCH v2 4/4 tools: move check-package out of support/scripts/
Ricardo, All,
On 2017-06-19 00:22 -0300, Ricardo Martincoski spake thusly:
Quoted 29 lines · Yann E. MORIN
Quoted 17 lines
--- support/scripts/check-package | 145 +-------------------- support/scripts/pkg-stats | 2 +- tools/00-README.txt | 4 + tools/check-package | 144 ++++++++++++++++++++ .../scripts => tools}/checkpackagelib/__init__.py | 0 {support/scripts => tools}/checkpackagelib/base.py | 0 {support/scripts => tools}/checkpackagelib/lib.py | 0 .../checkpackagelib/lib_config.py | 0 .../scripts => tools}/checkpackagelib/lib_hash.py | 0 .../scripts => tools}/checkpackagelib/lib_mk.py | 0 .../scripts => tools}/checkpackagelib/lib_patch.py | 0 .../scripts => tools}/checkpackagelib/readme.txt | 10 +- 12 files changed, 155 insertions(+), 150 deletions(-) mode change 100755 => 120000 support/scripts/check-package create mode 100755 tools/check-packageQuoted 8 lines
rename {support/scripts => tools}/checkpackagelib/__init__.py (100%) rename {support/scripts => tools}/checkpackagelib/base.py (100%) rename {support/scripts => tools}/checkpackagelib/lib.py (100%) rename {support/scripts => tools}/checkpackagelib/lib_config.py (100%) rename {support/scripts => tools}/checkpackagelib/lib_hash.py (100%) rename {support/scripts => tools}/checkpackagelib/lib_mk.py (100%) rename {support/scripts => tools}/checkpackagelib/lib_patch.py (100%) rename {support/scripts => tools}/checkpackagelib/readme.txt (91%)I forgot earlier...
Quoted 7 lines
Also the entry in the DEVELOPERS file must be updated
F: support/scripts/check*package*Probably if I didn't used '*' it would be easier to find. I didn't tested but I assume we could use
F:tools/check-package
F:tools/checkpackagelib/
I'll fix as you suggest, to drop the midle wildcard.
Also, you happen to have two entries in the DEVELOPPERS file, with two different emails:
1368 N:? Ricardo Martincoski <[email protected]> 1369 F:? package/atop/
and
1374 N:? Ricardo Martincoski <[email protected]> 1375 F:? support/scripts/check*package*
Is that expected?
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH v2 4/4 tools: move check-package out of support/scripts/
Hello,
Quoted 7 lines
Quoted 1 line · Yann E. MORIN
Also, you happen to have two entries in the DEVELOPPERS file, with two different emails:
1368 N:? Ricardo Martincoski <[email protected]> 1369 F:? package/atop/
Quoted 6 lines
and
1374 N:? Ricardo Martincoski <[email protected]> 1375 F:? support/scripts/check*package*
Is that expected?
Yes, professional and personal entries.
Regards,
Ricardo
v2 cover tools: add a directory to contain usefull user-facing tools
In reply to Yann E. MORINHello,
Quoted 9 lines · Yann E. MORIN
Currently, we provide a few user-facing utilities, like get-developers, in support/scripts/ . But this directory also contains internal scripts that a user should not be directly concerned with. Besides, it is two-level deep in the hierarchy, which is not really nice.
So, we introduce
tools/as a top-level directory, with the goal to store and expose all user-facing utilities, while keeping our internal scripts in support/scripts/ .
Quoted 6 lines
The first patch in the series introduces a new utility, brmake, a wrapper around make that stores all the output to a log file and displays only the >>> lines.
The second and subsequent patches each move a few user-facing utilities out of support/scripts/ and into
tools/.
I am wondering if there is a very clear cut boundary between user-facing tools and non-user facing tools.
For example, graph-build-time or graph-depends are internally used by the Buildroot Makefile, but may also be used directly. The size-stats tool is also used internally by the Buildroot Makefile, but size-stats-compare is meant to be used directly.
What about support/scripts/genimage.sh ?
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
v2 cover tools: add a directory to contain usefull user-facing tools
Thomas, All,
On 2017-06-18 16:15 +0200, Thomas Petazzoni spake thusly:
Quoted 14 lines · Yann E. MORIN
Quoted 13 lines
Currently, we provide a few user-facing utilities, like get-developers, in support/scripts/ . But this directory also contains internal scripts that a user should not be directly concerned with. Besides, it is two-level deep in the hierarchy, which is not really nice.
So, we introduce
tools/as a top-level directory, with the goal to store and expose all user-facing utilities, while keeping our internal scripts in support/scripts/ .The first patch in the series introduces a new utility, brmake, a wrapper around make that stores all the output to a log file and displays only the >>> lines.
Quoted 5 lines
Quoted 2 lines
The second and subsequent patches each move a few user-facing utilities out of support/scripts/ and into
tools/.I am wondering if there is a very clear cut boundary between user-facing tools and non-user facing tools.
Yes, the frontier is not trivial.
I'd say that if a tool is meant to be called by the user, then it belongs to tools/. If it is not meant to be alled by a user (even if it could be so) then it belongs to support/scripts/.
Quoted 2 lines
For example, graph-build-time or graph-depends are internally used by the Buildroot
Makefile, but may also be used directly.
The primary use for those scripts is still an internal use. They are supposed to be called from our infra.
Quoted 3 lines
The size-stats
tool is also used internally by the BuildrootMakefile, but size-stats-compare is meant to be used directly.
Then the former stays in support/scripts/ while the latter should move to tools/.
Quoted 1 line
What about
support/scripts/genimage.sh?
I would leave it to support/scripts/. It is an internal helper./ Besides, it needs a few of our variables (TARGET_DIR and BINARIES_DIR), so I see it as internal.
Of course, I might not have moved all that can/should be moved. This series serves as a base for further discussion.
See the initial submission:
[PATCH] contrib: add a directory to store "contrib" stuff
http://lists.busybox.net/pipermail/buildroot/2016-October/174238.html
Regards,
Yann E. MORIN.
Quoted 7 lines
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
v2 cover tools: add a directory to contain usefull user-facing tools
Quoted 20 lines · Yann E. MORIN
Thomas, All,
On 2017-06-18 16:15 +0200, Thomas Petazzoni spake thusly:
Quoted 17 lines · Yann E. MORIN
Quoted 15 lines
Currently, we provide a few user-facing utilities, like get-developers, in support/scripts/ . But this directory also contains internal scripts that a user should not be directly concerned with. Besides, it is two-level deep in the hierarchy, which is not really nice.
So, we introduce
tools/as a top-level directory, with the goal to store and expose all user-facing utilities, while keeping our internal scripts in support/scripts/ .The first patch in the series introduces a new utility, brmake, a wrapper around make that stores all the output to a log file and displays only the >>> lines.
The second and subsequent patches each move a few user-facing utilities out of support/scripts/ and into
tools/.
Quoted 8 lines
Quoted 2 lines
I am wondering if there is a very clear cut boundary between user-facing tools and non-user facing tools.
Yes, the frontier is not trivial.
I'd say that if a tool is meant to be called by the user, then it belongs to
tools/. If it is not meant to be alled by a user (even if it could be so) then it belongs to support/scripts/.
Sounds good to me!
Just to be clear: the main reason why I liked the idea of this directory is
because it makes it easier for users to discover these scripts.
Quoted 10 lines
Quoted 2 lines
For example, graph-build-time or graph-depends are internally used by the Buildroot
Makefile, but may also be used directly.The primary use for those scripts is still an internal use. They are supposed to be called from our infra.
Quoted 3 lines
The size-stats
tool is also used internally by the BuildrootMakefile, but size-stats-compare is meant to be used directly.
Quoted 8 lines
Then the former stays in support/scripts/ while the latter should move to
tools/.Quoted 1 line
What about
support/scripts/genimage.sh?I would leave it to support/scripts/. It is an internal helper./ Besides, it needs a few of our variables (
TARGET_DIRandBINARIES_DIR), so I see it as internal.
For me, that is a definite indication that it should stay in support/scripts.
Regards,
Arnout
Quoted 20 lines
Of course, I might not have moved all that can/should be moved. This series serves as a base for further discussion.
See the initial submission:
[PATCH] contrib: add a directory to store "contrib" stuff
http://lists.busybox.net/pipermail/buildroot/2016-October/174238.htmlRegards,
Yann E. MORIN.Quoted 7 lines
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Signature · 6 lines
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