From: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
"openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Subject: RE: [OE-core] [PATCH 2/2] oe-setup-builddir: Do not hardcode invalid paths for templates
Date: Thu, 22 Sep 2022 13:25:56 +0000 [thread overview]
Message-ID: <ee0aa31d5fa34a5ba889e3518d8b2a95@axis.com> (raw)
In-Reply-To: <28947223c26b05f58c4b6cd13919b025617318a2.camel@linuxfoundation.org>
> -----Original Message-----
> From: Richard Purdie <richard.purdie@linuxfoundation.org>
> Sent: den 22 september 2022 15:14
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 2/2] oe-setup-builddir: Do not hardcode invalid paths for templates
>
> On Thu, 2022-09-22 at 14:47 +0200, Peter Kjellerstedt wrote:
> > Previously, the paths "meta/conf" and "meta-poky/conf" were hardcoded
> > as invalid paths for templates. However, this is suboptimal for other
> > distros that are setup similarly to Poky. Instead, add support for a
> > new variable INVALID_TEMPLATECONFS, which takes a list of invalid
> > paths. It is expected that this variable is set in the .templateconf
> > file together with the default value for TEMPLATECONF, typically at
> > the same time that TEMPLATECONF is updated to match the new
> > requirements.
> >
> > Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> > ---
> > scripts/oe-setup-builddir | 21 +++++++++++++--------
> > 1 file changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
> > index 225919be92..c1148daf4f 100755
> > --- a/scripts/oe-setup-builddir
> > +++ b/scripts/oe-setup-builddir
> > @@ -34,14 +34,19 @@ chmod -st "$BUILDDIR/conf" 2>/dev/null || echo "WARNING: unable to chmod $BUILDD
> >
> > cd "$BUILDDIR" || die "Failed to change directory to $BUILDDIR!"
> >
> > -if [ -z "$TEMPLATECONF" ] && [ -f "$BUILDDIR/conf/templateconf.cfg" ]; then
> > - TEMPLATECONF=$(cat "$BUILDDIR/conf/templateconf.cfg")
> > - # The following two are no longer valid; unsetting them will automatically get them replaced
> > - # with correct ones.
> > - if [ "$TEMPLATECONF" = meta/conf ] || [ "$TEMPLATECONF" = meta-poky/conf ]; then
> > - unset TEMPLATECONF
> > - rm "$BUILDDIR/conf/templateconf.cfg"
> > - fi
> > +TEMPLATECONF_CFG="$BUILDDIR/conf/templateconf.cfg"
> > +if [ -z "$TEMPLATECONF" ] && [ -f "$TEMPLATECONF_CFG" ]; then
> > + TEMPLATECONF=$(cat "$TEMPLATECONF_CFG")
> > + # Unset TEMPLATECONF if it is set to a known invalid value to have it
> > + # automatically replaced with a correct one.
> > + for dir in $INVALID_TEMPLATECONFS; do
> > + if [ "$TEMPLATECONF" = "$dir" ]; then
> > + echo "WARNING: Removing $TEMPLATECONF_CFG as it contained the invalid value '$TEMPLATECONF'"
> > + unset TEMPLATECONF
> > + rm "$TEMPLATECONF_CFG"
> > + break;
> > + fi
> > + done
> > fi
>
> I've been trying to keep out this discussion but I really don't like
> piling in more complexity and more things we have to support because of
> a legacy code path we're trying to obsolete.
>
> I also suspect this is going to be used to "subvert" the move to try
> and standardise and if that happens, we may as well not have bothered
> making changes at all :(.
>
> As such I'm worried about this direction.
>
> Cheers,
>
> Richard
All I want is to remove the hardcoded superficial limitations and
allow us that provide distros setup just as Poky is setup to continue
to do so.
//Peter
next prev parent reply other threads:[~2022-09-22 13:26 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-22 12:47 [PATCH 1/2] .templateconf: Mark "meta/conf" as an invalid path for templates Peter Kjellerstedt
2022-09-22 12:47 ` [PATCH 2/2] oe-setup-builddir: Do not hardcode invalid paths " Peter Kjellerstedt
2022-09-22 13:14 ` [OE-core] " Richard Purdie
2022-09-22 13:25 ` Peter Kjellerstedt [this message]
2022-09-22 15:52 ` Alexander Kanavin
2022-09-22 19:56 ` Peter Kjellerstedt
2022-09-22 20:32 ` Richard Purdie
2022-09-22 21:53 ` Alexander Kanavin
[not found] ` <17174D5BCC8D1164.8129@lists.openembedded.org>
2022-09-26 17:09 ` Alexander Kanavin
2022-09-27 14:56 ` Peter Kjellerstedt
2022-09-27 15:29 ` Alexander Kanavin
[not found] ` <1718C14CEB633922.9698@lists.openembedded.org>
2022-09-27 15:42 ` Alexander Kanavin
2022-09-27 16:06 ` Peter Kjellerstedt
2022-09-27 16:16 ` Alexander Kanavin
2022-09-27 18:53 ` Peter Kjellerstedt
2022-09-27 19:58 ` Alexander Kanavin
2022-09-27 21:31 ` Peter Kjellerstedt
2022-09-27 21:50 ` Alexander Kanavin
2022-09-28 9:54 ` Peter Kjellerstedt
2022-09-28 10:59 ` Alexander Kanavin
2022-09-28 12:45 ` Peter Kjellerstedt
2022-09-28 13:24 ` Alexander Kanavin
[not found] ` <17190128C53AF22E.9603@lists.openembedded.org>
2022-09-28 11:05 ` Alexander Kanavin
2022-09-27 17:04 ` Alexander Kanavin
2022-09-27 19:22 ` Peter Kjellerstedt
2022-09-27 20:39 ` 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=ee0aa31d5fa34a5ba889e3518d8b2a95@axis.com \
--to=peter.kjellerstedt@axis.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.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