From: ChenQi <Qi.Chen@windriver.com>
To: Alexander Kanavin <alex.kanavin@gmail.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>,
Alexander Kanavin <alex@linutronix.de>
Subject: Re: [OE-core] [PATCH 1/7] scripts/oe-setup-builddir: add a check that TEMPLATECONF is valid
Date: Wed, 14 Sep 2022 15:42:06 +0800 [thread overview]
Message-ID: <8e5b3cc0-bf66-fb7c-0199-ae6766c76cc8@windriver.com> (raw)
In-Reply-To: <CANNYZj_OqjRgsQQwQditr1iHCM1RkZak-hFG-zEsqPmMfdNd_A@mail.gmail.com>
On 9/14/22 14:39, Alexander Kanavin wrote:
> On Wed, 14 Sept 2022 at 07:49, ChenQi <Qi.Chen@windriver.com> wrote:
>> I'm reluctant to agree that this is like machine and distro, because
>> it's a hard requirement that machine and distro definitions be under
>> some layer, otherwise how can bitbake get info about it? But
>> TEMPLATECONF seems to be a different case, it could be everywhere
>> because it's used by the project setup script.
>>
>> In our case, the TEMPLATECONF is <project_dir>/config/, and layers are
>> <project_dir>/<layer>/. This directory hierarchy has been working for
>> years until recent changes.
>>
>> Do you think such directory hierarchy makes sense? How about we deleting
>> such check if there's no strong technical reason to do so? By 'strong
>> technical reason', I mean that some codes in oe-core are written based
>> on this assumption (this is the part I'm sure about).
> Again, it's not about only code. It's about humans too: we benefit
> from having things where we expect them to be.
$TEMPLATECONF/bblayers.conf.sample has a list of layers. These layers
may have dependencies on each other or they may not. Which layer do you
think should this TEMPLATECONF locate?
TEMPLATECONF, by its nature, is a project setup variable. It logically
does not belong to any layer.
Why would people expect some project level variable to point to some
directory under a layer?
> If your templates are
> in meta-layer/conf/templates/ you do not have to document, explain or
> support this;
Again, why this meta-layer should have knowledge about the whole
project? It should be the project that has knowledge about layer, not
the other way around.
> anyone new to the project will simply pick this up from
> prior experience or official documentation.
When users see a file in a layer that refers to other layers which this
layer does not depend on and not been dependent upon, they may ask why.
>
> That said, there is already code that makes this assumption too: both
> 'bitbake-layers save-template-conf' and upcoming 'oe-setup-build' (the
> patch was sent for review here) consider only
> meta-layer/conf/templates.
Give it a second thought.
> I have to ask the same question to you: is there a strong technical
> reason that you cannot move the templates to the new standard
> location?
Yes. The bblayers.conf.sample is generated dynamically according to
project setup.
That said, I could of course create a useless layer that does nothing
but only holds these sample files to satisfy this sanity check. But I do
think this sanity check is logically wrong.
Again, project contains layers, project setup could choose to use layers
the project wants. Forcing a project level variable to point to a
location under a layer is not reasonable.
Regards,
Qi
> Alex
next prev parent reply other threads:[~2022-09-14 7:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-31 11:13 [PATCH 1/7] scripts/oe-setup-builddir: add a check that TEMPLATECONF is valid Alexander Kanavin
2022-08-31 11:13 ` [PATCH 2/7] bitbake-layers: add a command to save the active build configuration as a template into a layer Alexander Kanavin
2022-08-31 11:13 ` [PATCH 3/7] meta/files: add layer setup JSON schema and example Alexander Kanavin
2022-08-31 11:13 ` [PATCH 4/7] bitbake-layers: add ability to save current layer repository configuration into a file Alexander Kanavin
2022-08-31 11:13 ` [PATCH 5/7] scripts/oe-setup-layers: add a script that restores the layer configuration from a json file Alexander Kanavin
2022-08-31 11:14 ` [PATCH 6/7] selftest/bblayers: add a test for creating a layer setup and using it to restore the layers Alexander Kanavin
2022-08-31 11:14 ` [PATCH 7/7] selftest/bblayers: adjust the revision for the layer setup test Alexander Kanavin
2022-09-14 3:27 ` [OE-core] [PATCH 1/7] scripts/oe-setup-builddir: add a check that TEMPLATECONF is valid ChenQi
2022-09-14 5:00 ` Alexander Kanavin
2022-09-14 5:49 ` ChenQi
2022-09-14 6:39 ` Alexander Kanavin
2022-09-14 7:42 ` ChenQi [this message]
2022-09-14 8:03 ` Alexander Kanavin
2022-09-14 8:17 ` ChenQi
2022-09-14 8:42 ` Alexander Kanavin
2022-09-15 1:07 ` Peter Kjellerstedt
2022-09-15 9:20 ` Alexander Kanavin
2022-09-15 22:59 ` Peter Kjellerstedt
2022-09-16 10:57 ` Alexander Kanavin
2022-09-17 0:06 ` Peter Kjellerstedt
2022-09-17 8:17 ` 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=8e5b3cc0-bf66-fb7c-0199-ae6766c76cc8@windriver.com \
--to=qi.chen@windriver.com \
--cc=alex.kanavin@gmail.com \
--cc=alex@linutronix.de \
--cc=openembedded-core@lists.openembedded.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