From: Joshua Lock <joshua.g.lock@linux.intel.com>
To: "Aníbal Limón" <anibal.limon@linux.intel.com>,
"Patrick Ohly" <patrick.ohly@intel.com>
Cc: saul.wold@intel.com,
OpenEmbedded <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 2/2] scripts: Add yocto-compat-layer-wrapper
Date: Thu, 30 Mar 2017 17:58:01 +0100 [thread overview]
Message-ID: <1490893081.1227.5.camel@linux.intel.com> (raw)
In-Reply-To: <58DD3595.1060209@linux.intel.com>
On Thu, 2017-03-30 at 10:43 -0600, Aníbal Limón wrote:
>
> On 03/30/2017 10:13 AM, Patrick Ohly wrote:
> > On Thu, 2017-03-30 at 10:03 -0600, Aníbal Limón wrote:
> > >
> > > On 03/30/2017 12:02 AM, Patrick Ohly wrote:
> > > > On Wed, 2017-03-29 at 15:44 -0600, Aníbal Limón wrote:
> > > > ...
> > > > > +show_help() {
> > > > > + printf "Usage: %s [-o output_log] [-h] LAYER_DIR
> > > > > ...\n" $0
> > > > > +}
> > > > > +
> > > >
> > > > ...
> > > > > +env_dir=$(mktemp -d -t yocto-compat-XXXX)
> > > > > +echo "The environment will be setup at $env_dir"
> > > > > +echo ""
> > > >
> > > > The directory gets created, but not removed.
> > >
> > > I didn't remove the temp directory because may be the user wants
> > > to
> > > access the dir after the check.
> >
> > I think that this should be something that the user explicitly
> > needs to
> > request. As it is now, accumulating directories in /tmp when
> > invoking
> > the script is just unexpected and not the normal behavior of tools
> > creating something in /tmp.
>
> Ok, i will add an option to don't delete and change the default
> behavior
> to delete after check.
>
>
> >
> > > > > +echo "Cloning oe-core..."
> > > > > +git clone $oe_core_repo $env_dir
> > > > > +if [ $? -ne 0 ]; then
> > > > > + echo "Failed to clone oe-core repository"
> > > > > + exit 1
> > > > > +fi
> > > > > +
> > > > > +echo "Cloning bitbake..."
> > > > > +git clone $bitbake_repo $env_dir/bitbake
> > > > > +if [ $? -ne 0 ]; then
> > > > > + echo "Failed to clone bitbake repository"
> > > > > + exit 1
> > > > > +fi
> > > >
> > > > Cloning bitbake and OE-core each time the script runs will be
> > > > fairly
> > > > slow. There's also a chicken-and-egg problem: if you don't have
> > > > bitbake,
> > > > where's the script?
> > > >
> > > > I'd prefer to use an existing checkout of both, just as for the
> > > > layers
> > > > which are to be tested.
> > >
> > > I choose to clone the oe-core/bitbake to ensure there are a clean
> > > environment, without any previous layer added.
> >
> > I don't quite get that argument. When using existing bitbake and
> > OE-core
> > directories, how can they have layers added to them? I understand
> > that
> > the existing checkout might contain additional modifications and/or
> > might not match current master, but I consider that a feature. As
> > it
> > stands now, the caller of the script cannot test against Yocto 2.3
> > once
> > it is released, because the script will always check out master.
> >
> > Control over that can of course also be added to the script, but I
> > just
> > don't see the need for all this additional complexity. Just my 2
> > cents.
>
> That's the original issue to create this script, if a user tries to
> validate a layer and has modifications in configuration (bblayers,
> local, auto), the check will be contaminated in some how.
Those are all build-directory state, not items which are tracked in the
git repository.
Rather than cloning repositories to ensure clean state your script
could ensure a unique/new build directory by sourcing oe-init-build-env
with a non-standard build directory, perhaps checking whether the
directory exists first and adding random characters until you get
something new?
Joshua
next prev parent reply other threads:[~2017-03-30 16:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-29 21:44 [PATCH 1/2] scripts/lib/compatlayer: detect_layers always use realpath's Aníbal Limón
2017-03-29 21:44 ` [PATCH 2/2] scripts: Add yocto-compat-layer-wrapper Aníbal Limón
[not found] ` <1490853745.6396.439.camel@gmx.de>
[not found] ` <58DD2C5B.8010704@linux.intel.com>
2017-03-30 16:05 ` Aníbal Limón
2017-03-30 16:13 ` Patrick Ohly
2017-03-30 16:43 ` Aníbal Limón
2017-03-30 16:58 ` Joshua Lock [this message]
2017-03-30 17:07 ` Aníbal Limón
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=1490893081.1227.5.camel@linux.intel.com \
--to=joshua.g.lock@linux.intel.com \
--cc=anibal.limon@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=patrick.ohly@intel.com \
--cc=saul.wold@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.