From: Alexander Kanavin <alex.kanavin@gmail.com>
To: yocto@lists.yoctoproject.org, richard.purdie@linuxfoundation.org
Cc: bibibobibo@gmail.com
Subject: Re: [yocto] Yocto recipe file://DIRECTORY fetcher recursive tracking?
Date: Thu, 9 May 2024 16:37:17 +0200 [thread overview]
Message-ID: <CANNYZj_WYJeJY0OTzCGbO6S2+csFEzk0W1s5Z6seXkgTijOVoQ@mail.gmail.com> (raw)
In-Reply-To: <73820cf56fc9db54e88f9e827e448d79e56c6b62.camel@linuxfoundation.org>
On Thu, 9 May 2024 at 12:36, Richard Purdie via lists.yoctoproject.org
<richard.purdie=linuxfoundation.org@lists.yoctoproject.org> wrote:
> > I have a dummy question regarding the file://DIRECTORY/ in recipe
> > usage, we are using this mechanism to directly point at a source
> > repository with potentially lots of subfolders, etc. Does bitbake
> > track file://DIRECTORY tracks all contents accordingly (i.e something
> > will recursively walk through this directory and checksum each file,
> > then arrive at a final combined checksum?) and if we happen to repo-
> > sync or git-pull to pull new changes in DIRECTORY/, Yocto will be
> > able to detect any changes in this directory and automatically
> > rebuild this recipe.
> >
> > I was getting mixed answers from a few sources, some said this can
> > work, some said it works sometimes but not always. So I would like to
> > get a definitive answer from Yocto forum.
>
> It is meant to work. There have been some bugs in this area in the
> past, I believe they have been fixed. It also doesn't perform well with
> large trees of files from a speed perspective.
>
> Something like git allows for much faster operations as git is designed
> to do tracking of this kind of thing.
>
> So yes, it should work but isn't optimal with really large trees.
I'd also note that pointing to a source checkout that is external to
the layer checkout isn't good for build reproducibility. How do you
ensure each revision of the layer repository maps 1:1 to a specific
revision of the source repo? That's why recipes typically contain
git:// uris with source revisions, or http tarballs with tarball
checksums: to ensure everyone builds from the same source tree. It's
typically not a good idea to refer to anything that is not a part of
the layer.
Alex
prev parent reply other threads:[~2024-05-09 14:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <GfmG.1715197041107111792.DMO0@lists.yoctoproject.org>
2024-05-09 10:36 ` [yocto] Yocto recipe file://DIRECTORY fetcher recursive tracking? Richard Purdie
2024-05-09 14:37 ` Alexander Kanavin [this message]
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=CANNYZj_WYJeJY0OTzCGbO6S2+csFEzk0W1s5Z6seXkgTijOVoQ@mail.gmail.com \
--to=alex.kanavin@gmail.com \
--cc=bibibobibo@gmail.com \
--cc=richard.purdie@linuxfoundation.org \
--cc=yocto@lists.yoctoproject.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).