All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denys Dmytriyenko <denis@denix.org>
To: Jose Quaresma <quaresma.jose@gmail.com>
Cc: meta-ti@lists.yoctoproject.org
Subject: Re: [meta-ti] [master/kirkstone][PATCH] k3r5: ensure separate TMPDIR used for this multiconfig
Date: Tue, 21 Nov 2023 16:48:34 -0500	[thread overview]
Message-ID: <20231121214834.GC26739@denix.org> (raw)
In-Reply-To: <CANPvuRmdh8EteVzjJto1BgLYdiO1HGdUxihvsDrEYgv3YykOJg@mail.gmail.com>

On Mon, Nov 13, 2023 at 01:20:25PM +0000, Jose Quaresma wrote:
> Denys Dmytriyenko <denis@denix.org> escreveu no dia domingo, 12/11/2023
> à(s) 19:07:
> 
> > From: Denys Dmytriyenko <denys@konsulko.com>
> >
> > This k3r5 multiconfig builds baremetal components (and corresponding
> > native,
> > nativesdk and cross tools) and sets TCLIBC accordingly to "baremetal". The
> > expectation is that those components and tools will use a separate TMPDIR
> > to isolate from the main Linux build that uses "glibc" TCLIBC and to avoid
> > potential conflicts.
> >
> > OE-Core "nodistro" default configuration already sets TCLIBCAPPEND facility
> > to automatically add a suffix to TMPDIR, resulting in "tmp-baremetal" temp
> > directory for this multiconfig and "tmp-glibc" for the main Linux one.
> > Other
> > distros like Arago follow this convention and even extend a bit (e.g. Arago
> > also adds TCMODE suffix to TMPDIR for external toolchain support
> > separation).
> >
> > But Poky (and derivative distros, like AGL or YoE) disable TCLIBCAPPEND and
> > result in a combined TMPDIR, leading to potential conflicts, such as:
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=15273
> >
> > And that's just the beginning, there were other conflicts observed later in
> > the build, e.g. during nativesdk builds - that's why we also set a unique
> > SDKPKGSUFFIX here.
> >
> > To force a separate TMPDIR for k3r5 multiconfig, we have to directly append
> > a suffix to it. Multiple other options were tested in hopes of making it
> > slightly cleaner, but they either didn't work or were dismissed. For
> > example,
> > trying to override TCLIBCAPPEND getting cleared by a distro would require
> > using a machine/soc-override, which doesn't have enough scope (nativesdk)
> > or forcing it with :forcevariable would also change the main Linux TMPDIR
> > and affect existing CI flows. Also, using TCLIBC itself as a suffix to add
> > to TMPDIR may result in getting it appended twice (tmp-baremetal-baremetal)
> > when normal TCLIBCAPPEND facility is used. Hence the least
> > invasive/confusing
> > option is to always append "-k3r5" suffix to this multiconfig TMPDIR. That
> > results in "tmp-k3r5" in Poky (leaving main TMPDIR as "tmp"), while OE-Core
> > "nodistro" and Arago would end up with "tmp-baremetal-k3r5" (and
> > "tmp-glibc"
> > for the main).
> >
> > Also note, meta-ti-bsp layer.conf sets up images and sdks to be deployed
> > into a common location outside of TMPDIRs, but TI_COMMON_DEPLOY variable
> > that controls it is set weakly, allowing to be modified from a distro
> > configuration or local.conf. It means that all images and sdks can be
> > deployed into the main TMPDIR if one's CI flow expects tmp/deploy/ as
> > the final destination, by using := for immediate variable expansion:
> > TI_COMMON_DEPLOY := "${TMPDIR}/deploy"
> >
> > Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
> > ---
> >  meta-ti-bsp/conf/multiconfig/k3r5.conf | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/meta-ti-bsp/conf/multiconfig/k3r5.conf
> > b/meta-ti-bsp/conf/multiconfig/k3r5.conf
> > index 04b9a746..e36c87ed 100644
> > --- a/meta-ti-bsp/conf/multiconfig/k3r5.conf
> > +++ b/meta-ti-bsp/conf/multiconfig/k3r5.conf
> > @@ -4,4 +4,6 @@ DEPLOY_DIR_IMAGE:k3r5 =
> > "${TI_COMMON_DEPLOY}/images/${MAINMACHINE}"
> >
> >  MACHINE:append = "-k3r5"
> >  TCLIBC = "baremetal"
> > +TMPDIR:append = "-k3r5"
> > +
> >
> 
> Thanks for fixing this long remaining issue on the kirkstone branch.
> 
> AFAIK all the collision issues are mostly fixed on oe-core master.

Yes, there were several related fixes in oe-core master recently, correct. 
But not everything was fixes yet even in master.


> For me there are still sporadic failures with the SPDX bbclass.

And SPDX was one of the areas that seen collision fixes in master. 
Unfortunately, those fixes have very little chances to get backported 
to kirkstone. Hence this change.


> Can this change be optional? with something like:
> 
> TMPDIRAPPEND ?= "-k3r5"
> TMPDIR:append = "${TMPDIRAPPEND}"
> 
> This adds the possibility of more easily reverting this change
> to being able to fix what is pending in oe-core master.

The point of this fix was to force separate TMPDIRs to avoid potential 
breakage - I was not planning on making it optional...

The request seems to be very specific to layer/framework debugging purposes 
at which point this can be modified directly in the conf file. Allowing it to 
be disabled cleanly for a build seems dubious. But if there's a strong desire, 
I can send a v2...

-- 
Denys


  reply	other threads:[~2023-11-21 21:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-12 19:07 [master/kirkstone][PATCH] k3r5: ensure separate TMPDIR used for this multiconfig Denys Dmytriyenko
2023-11-13 13:20 ` [meta-ti] " Jose Quaresma
2023-11-21 21:48   ` Denys Dmytriyenko [this message]
2023-11-22 12:05     ` Jose Quaresma
     [not found] <1796F5B6A516DB9F.29291@lists.yoctoproject.org>
2023-11-20 20:17 ` Denys Dmytriyenko
2023-11-20 22:41   ` Ryan Eatmon

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=20231121214834.GC26739@denix.org \
    --to=denis@denix.org \
    --cc=meta-ti@lists.yoctoproject.org \
    --cc=quaresma.jose@gmail.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.