All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Denys Dmytriyenko" <denis@denix.org>
To: Sumit Garg <sumit.garg@linaro.org>
Cc: meta-arm@lists.yoctoproject.org, Denys Dmytriyenko <denys@ti.com>
Subject: Re: [meta-arm] [PATCH 2/4] external-arm-toolchain-versions: set per-components license based on version
Date: Wed, 17 Jun 2020 15:23:55 -0400	[thread overview]
Message-ID: <20200617192355.GZ17660@denix.org> (raw)
In-Reply-To: <CAFA6WYMN9Dz9yPTaL56iY6z__XRdc6etndDRsi1xKY2AbPQtBA@mail.gmail.com>

On Tue, Jun 16, 2020 at 11:21:08AM +0530, Sumit Garg wrote:
> On Mon, 15 Jun 2020 at 23:44, Denys Dmytriyenko <denis@denix.org> wrote:
> >
> > On Mon, Jun 15, 2020 at 04:25:13PM +0530, Sumit Garg wrote:
> > > On Mon, 15 Jun 2020 at 13:37, Denys Dmytriyenko <denis@denix.org> wrote:
> > > >
> > > > From: Denys Dmytriyenko <denys@ti.com>
> > > >
> > > > This code is upstreamed from meta-arago layer.
> > > >
> > > > Signed-off-by: Denys Dmytriyenko <denys@ti.com>
> > > > ---
> > > >  .../include/external-arm-toolchain-versions.inc    | 28 ++++++++++++++++++++++
> > > >  1 file changed, 28 insertions(+)
> > > >
> > > > diff --git a/meta-arm-toolchain/conf/distro/include/external-arm-toolchain-versions.inc b/meta-arm-toolchain/conf/distro/include/external-arm-toolchain-versions.inc
> > > > index a89f2f0..6121adf 100644
> > > > --- a/meta-arm-toolchain/conf/distro/include/external-arm-toolchain-versions.inc
> > > > +++ b/meta-arm-toolchain/conf/distro/include/external-arm-toolchain-versions.inc
> > > > @@ -126,6 +126,20 @@ def eat_get_bfd_version(d):
> > > >          first_line = stdout.splitlines()[0]
> > > >          return first_line.split()[-1]
> > > >
> > > > +# Licenses set for main components of the toolchain:
> > > > +# (g)libc is always LGPL version 2 (or later)
> > > > +# gcc has switched from GPL version 2 (or later) to version 3 (or later) after 4.2.1,
> > > > +#    see this announcement - http://gcc.gnu.org/ml/gcc-announce/2007/msg00003.html
> > > > +# libgcc and libstdc++ always had exceptions to GPL called Runtime Library Exception, but
> > > > +#    it was based on GPL version 2 (or later), until new GPL version 3 (or later) exception
> > > > +#    was introduced on 27 Jan 2009 - http://gcc.gnu.org/ml/gcc-announce/2009/msg00000.html
> > > > +#    and http://www.gnu.org/licenses/gcc-exception.html, which was several days after
> > > > +#    gcc 4.3.3 was released - http://gcc.gnu.org/releases.html
> > > > +# gdb/gdbserver version 6.6 was the last one under GPL version 2 (or later), according
> > > > +#    to the release schedule - http://www.gnu.org/software/gdb/schedule/
> > > > +# binutils version 2.17 was the last one under GPL version 2 (or later), according
> > > > +#    to the published releases - http://ftp.gnu.org/gnu/binutils/
> > > > +
> > > >  python external_arm_toolchain_version_handler () {
> > > >      if not isinstance(e, bb.event.ConfigParsed):
> > > >          return
> > > > @@ -139,5 +153,19 @@ python external_arm_toolchain_version_handler () {
> > > >      d.setVar('EAT_VER_KERNEL', eat_get_kernel_version(ld))
> > > >      d.setVar('EAT_VER_GDB', eat_get_gdb_version(ld))
> > > >      d.setVar('EAT_VER_BFD', eat_get_bfd_version(ld))
> > > > +
> > > > +    lc_libc = "LGPL-2.1"
> > > > +    lc_gcc = ["GPL-3.0", "GPL-2.0"][eat_get_gcc_version(ld) <= "4.2.1"]
> > > > +    lc_rle = ["GPL-3.0-with-GCC-exception", "GPL-2.0-with-GCC-exception"][eat_get_gcc_version(ld) <= "4.3.3"]
> > > > +    lc_gdb = ["GPL-3.0", "GPL-2.0"][eat_get_gdb_version(ld) <= "6.6"]
> > > > +    lc_bfd = ["GPL-3.0", "GPL-2.0"][eat_get_bfd_version(ld) <= "2.17"]
> > > > +
> > > > +    d.setVar('EAT_LIBC_LICENSE', lc_libc)
> > > > +    d.setVar('EAT_GCC_LICENSE', lc_gcc)
> > > > +    d.setVar('EAT_RLE_LICENSE', lc_rle)
> > > > +    d.setVar('EAT_GDB_LICENSE', lc_gdb)
> > > > +    d.setVar('EAT_BFD_LICENSE', lc_bfd)
> > > > +
> > > > +    d.setVar('EAT_LICENSE', "%s & %s & %s & %s & %s" % (lc_libc, lc_gcc, lc_rle, lc_gdb, lc_bfd))
> > >
> > > Do we really need this dynamic computation of license based on
> > > toolchain versions? As pre-built GNU Arm toolchains [1] only support
> > > versions > 8.
> >
> > I needed gcc, gdb and binutils licenses set in central location for the new
> > recipe and I already had this code handy, so I just copied it over.
> >
> > I guess we can drop the conditional part of it and set the vars statically.
> > But setting them here is better than in the recipe, as they can be re-used
> > in multiple recipes.
> >
> 
> Sounds reasonable. Could you rebase it on top of mine patch-set and
> let license.inc [1] reuse these static defines?

Sure, will do.


> [1] https://lists.yoctoproject.org/g/meta-arm/message/647
> 
> -Sumit
> 
> > --
> > Denys
> >
> >
> > > [1] https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads
> > >
> > > -Sumit
> > >
> > > >  }
> > > >  addhandler external_arm_toolchain_version_handler
> > > > --
> > > > 2.7.4
> > > >
> > > > 
> > >
> 

  reply	other threads:[~2020-06-17 19:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-15  8:07 [PATCH 1/4] external-arm-toolchain-versions: also collect binutils/bfd version Denys Dmytriyenko
2020-06-15  8:07 ` [PATCH 2/4] external-arm-toolchain-versions: set per-components license based on version Denys Dmytriyenko
2020-06-15 10:55   ` [meta-arm] " Sumit Garg
2020-06-15 18:14     ` Denys Dmytriyenko
2020-06-16  5:51       ` Sumit Garg
2020-06-17 19:23         ` Denys Dmytriyenko [this message]
2020-06-15  8:07 ` [PATCH 3/4] external-arm-toolchain: check for TCLIBC being glibc Denys Dmytriyenko
2020-06-15  8:07 ` [PATCH 4/4] external-arm-sdk-toolchain: add recipe to package gcc/gdb/binutils cross binaries Denys Dmytriyenko
2020-06-15 12:45   ` [meta-arm] " Sumit Garg
2020-06-15 18:20     ` Denys Dmytriyenko
2020-06-16  5:56       ` Sumit Garg
2020-06-18  3:29         ` Denys Dmytriyenko

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=20200617192355.GZ17660@denix.org \
    --to=denis@denix.org \
    --cc=denys@ti.com \
    --cc=meta-arm@lists.yoctoproject.org \
    --cc=sumit.garg@linaro.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.