From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 4/6] toolchain-external: update Linaro AArch64 toolchains
Date: Thu, 2 Jan 2014 14:29:06 +0100 [thread overview]
Message-ID: <20140102142906.6ae2d2d7@skate> (raw)
In-Reply-To: <CAAXf6LW+E2KLPs8y88SCYe_eXJOMEAg9rGQyr+vcib+Ttn1cWw@mail.gmail.com>
Dear Thomas De Schampheleire,
Happy new year!
On Thu, 2 Jan 2014 14:17:31 +0100, Thomas De Schampheleire wrote:
> While I agree that the existing patchset could continue in the
> meanwhile, I think it is worth revisiting the core discussion. For
> reference, here is the previous discussion:
> http://lists.busybox.net/pipermail/buildroot/2013-October/080119.html
>
> Back then (October) there was not much debate about the idea of only
> providing sufficiently-different versions of the Linaro toolchains.
> The biggest problem was how to identify the toolchains so that 'minor'
> updates can keep the same config symbol (and thus be transparent to
> users). This boils down to the question: which parts of the toolchain
> may change to continue considering it as 'the same' toolchain.
> I think everyone will agree that a new gcc version or a new C library
> version means a different toolchain.
> However, what about the other parts? If Linaro updates binutils, do we
> consider it the same toolchain or not?
>
> Based on this we could devise some logical names of the config symbols.
> Note that this does not mean we can't change our minds later. Suppose
> we start with the gcc/libc combination as key, and we'd have symbols
> LINARO_GCC_4_8_GLIBC_2_17
> LINARO_GCC_4_8_GLIBC_2_18
> LINARO_GCC_5_0_GLIBC_2_18
>
> and suddenly Linaro releases a toolchain with the same gcc and glibc
> version, but some other change that we consider as significant. Then
> at that point we can simply introduce a new symbol and keep both, for
> example:
> LINARO_GCC_4_8_GLIBC_2_17
> LINARO_GCC_4_8_GLIBC_2_18
> LINARO_GCC_5_0_GLIBC_2_18
> LINARO_GCC_5_0_GLIBC_2_18_OTHER_FEATURE
>
> Does this make sense? Did I overlook something?
My personal view on this is that I still don't really understand what
is the problem with the current naming scheme. If an user upgrades from
one Buildroot version to another then the version of all components
*are* changing, without changes to the corresponding Config.in symbol.
You update Buildroot, then suddenly you get Qt 5.2 instead of Qt 5.1,
without being notified. At the next Buildroot upgrade, you may still be
using Qt 5.2, or Qt 5.2.1, or Qt 5.3, or 5.4. You have to verify it.
With Linaro toolchains, if you use Linaro 2013.02 in your Buildroot
configuration, then update to a new Buildroot version that still has
Linaro 2013.02, then you will continue to use this toolchain. However,
if Buildroot has updated a number of Linaro toolchains, and 2013.02 is
no longer available, you will automatically default to the latest
Linaro toolchain that exists for your architecture, maybe 2013.06 or
2013.07.
What's the difference with Qt? I don't see any, to be honest.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2014-01-02 13:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-27 11:32 [Buildroot] [PATCH 0/6] Various external toolchain updates Thomas Petazzoni
2013-12-27 11:32 ` [Buildroot] [PATCH 1/6] toolchain-external: add Sourcery ARM 2013.11, remove Sourcery ARM 2011.09 Thomas Petazzoni
2013-12-29 17:19 ` Yann E. MORIN
2013-12-27 11:32 ` [Buildroot] [PATCH 2/6] toolchain-external: add Sourcery MIPS 2013.11, remove Sourcery MIPS 2012.03 Thomas Petazzoni
2013-12-27 11:56 ` Baruch Siach
2013-12-29 17:26 ` Yann E. MORIN
2013-12-27 11:32 ` [Buildroot] [PATCH 3/6] toolchain-external: update Linaro ARM toolchains Thomas Petazzoni
2013-12-27 11:32 ` [Buildroot] [PATCH 4/6] toolchain-external: update Linaro AArch64 toolchains Thomas Petazzoni
2013-12-29 17:32 ` Yann E. MORIN
2013-12-29 17:40 ` Thomas De Schampheleire
2013-12-29 17:53 ` Thomas Petazzoni
2013-12-29 21:51 ` Peter Korsgaard
2014-01-02 13:17 ` Thomas De Schampheleire
2014-01-02 13:29 ` Thomas Petazzoni [this message]
2014-01-02 14:13 ` Thomas De Schampheleire
2013-12-27 11:32 ` [Buildroot] [PATCH 5/6] toolchain-external: mark Microblaze external toolchains as deprecated Thomas Petazzoni
2013-12-29 17:38 ` Yann E. MORIN
2013-12-27 11:32 ` [Buildroot] [PATCH 6/6] toolchain-external: add support for the Blackfin 2013R1 toolchain Thomas Petazzoni
2013-12-29 17:40 ` Yann E. MORIN
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=20140102142906.6ae2d2d7@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/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