public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
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




  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