All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Lehtonen <markus.lehtonen@linux.intel.com>
To: "Keskinarkaus, Teemu" <Teemu.Keskinarkaus@Maximatecc.com>,
	Paul Eggleton <paul.eggleton@linux.intel.com>,
	Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Cc: "poky@yoctoproject.org" <poky@yoctoproject.org>
Subject: Re: Recompiles in Yocto/Poky
Date: Mon, 27 Jun 2016 14:00:17 +0300	[thread overview]
Message-ID: <1467025217.6738.14.camel@linux.intel.com> (raw)
In-Reply-To: <83DB4EC8FADD45428E3CC4E3664761FD400438B4@AMDTCEX15.actuant.pri>

Hi,

There would be at least two options,that I can think of to "hide" the
files. First, if possible, make the recipe build in a separate
directory so that the build-time generated files won't pollute your
source tree. Second, make your external source tree a Git tree and add
the files in question to .gitignore. 

Thanks,
  Markus

On Wed, 2016-06-08 at 04:50 +0000, Keskinarkaus, Teemu wrote:
> Hi,
> 
> I think there are some files that are being generated at compilation
> time so most likely those triggers the recompilation every time.
> 
> The next question is that how to I 'hide' files so that they don't
> trigger the recompilation? Is that something that I need to do on my
> application side or can I list files in Yocto to ignore when hashing
> files? This is most likely the proper way to deal with this issue
> rather than disabling whole feature.
> 
> Teemu Keskinarkaus
> Software system engineer
> maximatecc
> making machines smart, safe and productive
> 
> 
> -----Original Message-----
> From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
> Sent: 8. kesäkuuta 2016 4:52
> To: Peter Kjellerstedt; Keskinarkaus, Teemu
> Cc: poky@yoctoproject.org
> Subject: Re: [poky] Recompiles in Yocto/Poky
> 
> On Fri, 03 Jun 2016 07:00:14 Peter Kjellerstedt wrote:
> > This is a feature introduced to complement the main use of
> > externalsrc, which is together with devtool. When you use "devtool
> > modify -x <recipe>", it fetches the sources as specified in the
> > recipe
> > and makes them available locally. At the same time it sets up a
> > bbappend in the workspace layer which uses externalsrc to use those
> > sources when building the recipe. This is intended to make it easy
> > to
> > use BitBake to actually work on and develop the sources. However,
> > for
> > this to work in practice, BitBake must rebuild the package if there
> > are any changes in the sources, but since BitBake normally only
> > looks
> > at the meta data to determine if a recipe task needs to run, there
> > is
> > nothing telling it that the sources have changed. Therefore changes
> > were made so that code specified using externalsrc is always
> > rebuilt.
> 
> In 2.0 that's how it behaved - what it's supposed to do in 2.1 is
> determine if the sources have changed by either relying on the git
> metadata (if the source tree is tracked in git) or by hashing all
> files in the source tree if it isn't. It could be false triggering if
> you have files in the source tree that get regenerated as part of the
> compilation process that aren't hidden. Teemu, is that the case for
> your source tree?
> 
> Unfortunately there is no way at present to turn off this
> functionality; we could add one, however before doing that I would be
> more interested in looking at making the code more intelligent so it
> did automatically rebuild in response to source changes for this case
> and not when there were no changes, assuming that's practical.
> 
> Cheers,
> Paul
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> 
> ________________________________
> 
> Actuant Corporation Email Notice
> 
> This message is intended only for the use of the Addressee and may
> contain information that is PRIVILEGED and/or CONFIDENTIAL.
> This email is intended only for the personal and confidential use of
> the recipient(s) named above. If the reader of this email is not an
> intended recipient, you have received this email in error and any
> review, dissemination, distribution or copying is strictly
> prohibited.
> If you have received this email in error, please notify the sender
> immediately by return mail and permanently delete the copy you
> received.
> 
> Thank you.



      parent reply	other threads:[~2016-06-27 11:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-02  4:28 Recompiles in Yocto/Poky Keskinarkaus, Teemu
2016-06-03  7:00 ` Peter Kjellerstedt
2016-06-03  7:04   ` Keskinarkaus, Teemu
2016-06-08  1:52   ` Paul Eggleton
2016-06-08  4:50     ` Keskinarkaus, Teemu
2016-06-08  4:56       ` Paul Eggleton
2016-06-08  5:00         ` Keskinarkaus, Teemu
2016-06-27 11:00       ` Markus Lehtonen [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=1467025217.6738.14.camel@linux.intel.com \
    --to=markus.lehtonen@linux.intel.com \
    --cc=Teemu.Keskinarkaus@Maximatecc.com \
    --cc=paul.eggleton@linux.intel.com \
    --cc=peter.kjellerstedt@axis.com \
    --cc=poky@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 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.