From: "Marcelo E. Magallon" <marcelo.magallon@hpe.com>
To: "Koehler, Yannick" <yannick.koehler@hpe.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: externalsrc + sstate why is not compatible?
Date: Wed, 6 Dec 2017 12:45:59 -0600 [thread overview]
Message-ID: <20171206184557.3mxnbq6h6x4hebqh@nyx.americas.hpqcorp.net> (raw)
In-Reply-To: <CS1PR8401MB0840A114AD0B63DF969D818BED320@CS1PR8401MB0840.NAMPRD84.PROD.OUTLOOK.COM>
On Wed, Dec 06, 2017 at 10:59:37AM -0600, Koehler, Yannick wrote:
> Ok, will try that. If that works, I may see if I can alter the file
> fetcher to use symlinks, not sure if sstate subsystem will like that
> or not.
That was my idea, but I've never tried it. I'm sure the devil is in the
details. If you can elide the copy and simply replace it with a symlink,
you'd get faster builds.
> If we do so, and someone change the file in /src/somedir will yocto
> redo the fetch/unpack pattern to recopy over the original content by
> itself?
Yes, it does. You change a file, and the fetcher runs again. This means
S and B are deleted (if split), do_fetch runs again and S is populated
fresh. do_configure and do_compile populate B again.
Once you get that working, people will complain as to why the system is
rebuilding everything instead of just the file that changed :-) It might
work "as expected" if S = B, and your build system in the module is
smart enough to produce the correct dependencies (e.g. cmake or bazel).
Marcelo
next prev parent reply other threads:[~2017-12-06 18:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-06 2:15 externalsrc + sstate why is not compatible? Koehler, Yannick
2017-12-06 8:47 ` Alexander Kanavin
2017-12-06 14:13 ` Koehler, Yannick
2017-12-06 14:47 ` Marcelo E. Magallon
2017-12-06 16:59 ` Koehler, Yannick
2017-12-06 18:45 ` Marcelo E. Magallon [this message]
2017-12-06 18:51 ` Koehler, Yannick
2017-12-06 17:27 ` Alexander Kanavin
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=20171206184557.3mxnbq6h6x4hebqh@nyx.americas.hpqcorp.net \
--to=marcelo.magallon@hpe.com \
--cc=yannick.koehler@hpe.com \
--cc=yocto@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.