All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] libcomps: put PV in filename
Date: Wed, 27 Mar 2019 15:20:40 +0100	[thread overview]
Message-ID: <20190327142040.GB1598@jama> (raw)
In-Reply-To: <20190327140327.GA21936@localhost>

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

On Wed, Mar 27, 2019 at 04:03:27PM +0200, Adrian Bunk wrote:
> On Wed, Mar 27, 2019 at 02:33:14PM +0100, Martin Jansa wrote:
> > On Tue, Mar 26, 2019 at 12:42:12PM +0200, Adrian Bunk wrote:
> >...
> > > Not having the release there also loses the ability to use either
> > > gcc_%.bbappend or gcc_8.3.0.bbappend, which are suitable for
> > > different situations.
> > 
> > There is usually just one version per recipe and even with _git.bb
> > suffix you can easily do gcc_7+git.bb and gcc_8+git.bb if you need to.
> 
> Thud contains 8.2 today, but might have 8.3 tomorrow.
> 
> A layer might want to append only to one of them,
> or have different appends for different versions.
> 
> That's trivial with gcc_8.2.bb and gcc_8.3.bb,
> and harder with gcc_8+svn.bb.

If your layer has gcc_8.2.bbappend and the recipe in oe-core gets
renamed from gcc_8.2.bb to gcc_8.3.bb in newer thud revision, then your
bbappend will not apply and bitbake will complain that there is no
recipe for your gcc_8.2.bbappend.

Layer which doesn't even parse correctly with different revisions of
the same thud branch isn't really something we should encourage.

gcc_8%.bbappend with some logic inside (e.g. adding some .patch file
only when PV starts with 8.2) will be compatible with both newer and
older revision of thud.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

  reply	other threads:[~2019-03-27 14:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-25 23:44 [PATCH] libcomps: put PV in filename Ross Burton
2019-03-26  1:39 ` Khem Raj
2019-03-26 10:00   ` Burton, Ross
2019-03-26 10:20     ` Martin Jansa
2019-03-26 10:32       ` Burton, Ross
2019-03-26 11:01         ` Martin Jansa
2019-03-26 11:06           ` Burton, Ross
2019-03-26 10:42       ` Adrian Bunk
2019-03-27 13:33         ` Martin Jansa
2019-03-27 14:03           ` Adrian Bunk
2019-03-27 14:20             ` Martin Jansa [this message]
2019-03-26 18:12     ` Khem Raj
2019-03-29 18:45 ` Böszörményi Zoltán
2019-03-29 18:46   ` Böszörményi Zoltán
  -- strict thread matches above, loose matches on Subject: below --
2019-03-04 11:58 Ross Burton
2019-03-04 15:12 ` Richard Purdie
2019-03-04 16:33   ` Burton, Ross

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=20190327142040.GB1598@jama \
    --to=martin.jansa@gmail.com \
    --cc=bunk@stusta.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 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.