Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mike Crowe <mac@mcrowe.com>
To: Alexander Kanavin <alex.kanavin@gmail.com>,
	Julien Stephan <jstephan@baylibre.com>,
	openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] Using devtool without an absolute path to the workspace in bblayers.conf
Date: Thu, 19 Oct 2023 15:44:32 +0100	[thread overview]
Message-ID: <ZTFA0P4HlE6htl13@mcrowe.com> (raw)
In-Reply-To: <CANNYZj8e6Lqkb+D6RKhEtVidaMhRUgE3YKg=Jqa4kP-ghV6C9w@mail.gmail.com>

On Thursday 19 October 2023 at 14:51:56 +0200, Alexander Kanavin wrote:
> On Thu, 19 Oct 2023 at 14:33, Mike Crowe via lists.openembedded.org
> <mac=mcrowe.com@lists.openembedded.org> wrote:
> > We do need to modify bblayers.conf from time to time to add and remove
> > layers.
> >
> > Using templates might be possible, but it would appear that this would
> > force developers to manually incorporate changes (or just wipe their
> > bblayers.conf file) when the template changes. Just keeping bblayers.conf
> > under version control doesn't suffer from that problem.
> 
> Generally content of build/conf/, or anything else in build/ is not
> designed for being under version control. You may be able to get away
> with it by coincidence, but it's neither documented nor tested, and so
> any issues are your own.
> 
> I don't have a quick solution to ensure that templates and
> configurations coming from them are strictly in sync, but welcome to
> suggestions. People modify local.conf and bblayers.conf all the time
> as well for local experiments, you're simply not supposed to lock them
> down.

There's no problem with modifying them for local experiments, even if they
are under version control, but it's clear when those experiments need to be
committed that those files need to be committed too.

However, it's clear that I'm pushing against the tide. I'll stick with the
early-return hack in devtool for the short term to see if we come across
any other reasons to make changes or any other breakage. Once everything is
working I'll investigate our options for not keeping bblayers.conf under
version control.

Thanks for you help.

Mike.


  reply	other threads:[~2023-10-19 14:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-18 14:29 Using devtool without an absolute path to the workspace in bblayers.conf Mike Crowe
2023-10-18 15:47 ` [OE-core] " Julien Stephan
2023-10-19 12:33   ` Mike Crowe
2023-10-19 12:51     ` Alexander Kanavin
2023-10-19 14:44       ` Mike Crowe [this message]
2023-10-18 16:19 ` Khem Raj
2023-10-18 16:28   ` Mike Crowe
2023-10-18 17:21     ` Khem Raj

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=ZTFA0P4HlE6htl13@mcrowe.com \
    --to=mac@mcrowe.com \
    --cc=alex.kanavin@gmail.com \
    --cc=jstephan@baylibre.com \
    --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