Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/7 v4] docs/manual: document the test-pkg script
Date: Thu, 16 Feb 2017 18:21:11 +0100	[thread overview]
Message-ID: <20170216172111.GA4986@free.fr> (raw)
In-Reply-To: <20170215232547.24a6cb92@free-electrons.com>

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.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2017-02-16 17:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 22:25   ` Thomas Petazzoni
2017-02-16 17:21     ` Yann E. MORIN [this message]
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 ` [Buildroot] [PATCH 3/7 v4] support/test-pkg: print number of toolchain and progress 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
2017-02-15 21:44 ` [Buildroot] [PATCH 5/7 v4] support/test-pkg: cannonicalize paths early Yann E. MORIN
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 ` [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
2017-04-05 19:16   ` Yann E. MORIN
2017-04-06  8:48     ` Arnout Vandecappelle
2017-04-06 15:55       ` Yann E. MORIN
2017-04-06 17:19         ` Arnout Vandecappelle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170216172111.GA4986@free.fr \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox