Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 2/5] support/testing: add core tests
Date: Sun, 5 Mar 2017 18:54:36 +0100	[thread overview]
Message-ID: <20170305185436.00822de9@free-electrons.com> (raw)
In-Reply-To: <20170305160001.GI3671@free.fr>

Hello,

On Sun, 5 Mar 2017 17:00:01 +0100, Yann E. MORIN wrote:

> >  support/testing/tests/core/__init__.py             |   0
> >  support/testing/tests/core/post-build.sh           |  10 ++++
> >  support/testing/tests/core/post-image.sh           |  10 ++++
> >  .../testing/tests/core/rootfs-overlay1/test-file1  | Bin 0 -> 4096 bytes
> >  .../tests/core/rootfs-overlay2/etc/test-file2      | Bin 0 -> 8192 bytes  
> 
> What are those two binary blobs for?
> Why are they binary blobs?
> Can't they be generated locally?

They are just here to avoid some files containing random stuff, we
don't care what they contain. So indeed, they could be generated
instead of stored in the repository.

However, right now, the testing infrastructure doesn't allow a test to
run some custom operations *before* the build is started. But it's
clearly something that will be needed for a significant number of
tests, so we definitely want to add something like that.

> > +#!/bin/sh
> > +echo $1 > ${BUILD_DIR}/post-build.log
> > +echo $2 >> ${BUILD_DIR}/post-build.log
> > +echo $3 >> ${BUILD_DIR}/post-build.log
> > +echo ${TARGET_DIR}  >> ${BUILD_DIR}/post-build.log
> > +echo ${BUILD_DIR}   >> ${BUILD_DIR}/post-build.log
> > +echo ${HOST_DIR}    >> ${BUILD_DIR}/post-build.log
> > +echo ${STAGING_DIR} >> ${BUILD_DIR}/post-build.log
> > +echo ${BINARIES_DIR}  >> ${BUILD_DIR}/post-build.log
> > +echo ${BR2_CONFIG}  >> ${BUILD_DIR}/post-build.log  
> 
> This is ugly, and I guess it will be hard to maintain consistency
> between this list and the checks done in the code.

I wouldn't call it "ugly", but it indeed could be better.

> This does not work well if there are any problematice character in
> there, so I'd at least quote the variables.
> 
> But I would even go further and print key-value pairs to the file:
> 
>     #!/bin/sh
>     printf "what='%s'\n" "${1}"
>     printf "arg2='%s'\n" "${2}"
>     printf "arg3='%s'\n" "${2}"
>     printf "TARGET_DIR='%s'\n" "${TARGET_DIR}"
>     printf "BUILD_DIR='%s'\n" "${BUILD_DIR}"
>     [...]
> 
> And then use a parser [*] to read that file and store the values in an
> associative array (aka dictionnary) in the python code, then you can do
> things like:
> 
>     self.assert(post_log["what"], os.path.join(self.builddir, what))
>     self.assert(post_log["TARGET_DIR"], os.path.join(self.builddir, "target"))
> 
> and so on... Which is much more readable IMHO...
> 
> [*] I don't know which parser, but probably one that can read key-value
> pairs from a file... ;-)  Python experts may help you here... ;-]

Not sure which parser to use here. Perhaps some sort of CSV file is
easier to parse in Python.

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

  reply	other threads:[~2017-03-05 17:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-05 15:03 [Buildroot] [PATCH v2 0/5] Runtime testing infrastructure Thomas Petazzoni
2017-03-05 15:03 ` [Buildroot] [PATCH v2 1/5] support/testing: core " Thomas Petazzoni
2017-03-05 15:03 ` [Buildroot] [PATCH v2 2/5] support/testing: add core tests Thomas Petazzoni
2017-03-05 16:00   ` Yann E. MORIN
2017-03-05 17:54     ` Thomas Petazzoni [this message]
2017-03-05 15:03 ` [Buildroot] [PATCH v2 3/5] support/testing: add fs tests Thomas Petazzoni
2017-03-05 15:03 ` [Buildroot] [PATCH v2 4/5] support/testing: add package tests Thomas Petazzoni
2017-03-05 16:27   ` Yann E. MORIN
2017-03-05 17:55     ` Thomas Petazzoni
2017-03-05 15:03 ` [Buildroot] [PATCH v2 5/5] support/testing: add toolchain tests Thomas Petazzoni
2017-03-05 21:30   ` Ricardo Martincoski
2017-03-05 21:36     ` Thomas Petazzoni
2017-03-06  0:41       ` Ricardo Martincoski

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=20170305185436.00822de9@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --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