Patchwork toolchain/crostool-NG: mark as deprecated

login
register
mail settings
Submitter Yann E. MORIN
Date May 6, 2013, 10:47 p.m.
Message ID <1367880422-12739-1-git-send-email-yann.morin.1998@free.fr>
Download mbox | patch
Permalink /patch/241811/
State Accepted
Commit 8fda9b78133ae97b373489c3d5fd088ae2b39484
Headers show

Comments

Yann E. MORIN - May 6, 2013, 10:47 p.m.
From: "Yann E. MORIN" <yann.morin.1998@free.fr>

For the following reasons:
  - it used to be broken without anyone noticing for a long time,
  - it is still not fully integrated within the Buildroot set of options,
  - it has not gained much traction (not even I use it),
  - I've always argued that sustained development should use an external
    toolchain, and not rely on building one with Buildroot,
  - I did not submit any of the enhancements requested during the last
    developpers' day in Brussels,
  - I have neither the incentive nor the time to maintain and enhance it,

it is time to deprecate the crosstool-NG backend for the 2013.05 release.

Then, it will be entirely removed early in the 2013.08 cycle, to let some
time for those that rely on it to voice their opinions. ;-)

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 toolchain/Config.in | 1 +
 1 file changed, 1 insertion(+)
Thomas Petazzoni - May 7, 2013, 8:02 a.m.
Dear Yann E. MORIN,

On Tue,  7 May 2013 00:47:02 +0200, Yann E. MORIN wrote:
> From: "Yann E. MORIN" <yann.morin.1998@free.fr>
> 
> For the following reasons:
>   - it used to be broken without anyone noticing for a long time,
>   - it is still not fully integrated within the Buildroot set of options,
>   - it has not gained much traction (not even I use it),
>   - I've always argued that sustained development should use an external
>     toolchain, and not rely on building one with Buildroot,
>   - I did not submit any of the enhancements requested during the last
>     developpers' day in Brussels,
>   - I have neither the incentive nor the time to maintain and enhance it,
> 
> it is time to deprecate the crosstool-NG backend for the 2013.05 release.
> 
> Then, it will be entirely removed early in the 2013.08 cycle, to let some
> time for those that rely on it to voice their opinions. ;-)

I don't have real comments about the proposal to deprecate the
Crosstool-NG support, but I'd like to take this opportunity to unveil
my plans about the internal toolchain support (I hate unveiling plans
before the code is ready, but it seems like a good idea in this
particular case) :

 (1) I am currently converting the existing internal toolchain logic to
     use the package infrastructure. I've already done it for
     'gdb' (merged for 2013.05), I have patches that seem to work for
     elf2flt and linux-headers, and I've started working on converting
     gcc (which is the most complicated piece of the puzzle).

 (2) Once this conversion is done, I intend to work on adding (e)glibc
     support to the internal toolchain backend, so that regardless of
     what happens with the Crosstool-NG backend, Buildroot will
     continue to have the possibility to build a (e)glibc toolchain.

(1) and (2) represent a significant amount of work, so don't expect
those things to be ready overnight.

Best regards,

Thomas
Jeremy Rosen - May 7, 2013, 8:20 a.m.
> 
> I don't have real comments about the proposal to deprecate the
> Crosstool-NG support, but I'd like to take this opportunity to unveil
> my plans about the internal toolchain support (I hate unveiling plans
> before the code is ready, but it seems like a good idea in this
> particular case) :
> 
>  (1) I am currently converting the existing internal toolchain logic
>  to
>      use the package infrastructure. I've already done it for
>      'gdb' (merged for 2013.05), I have patches that seem to work for
>      elf2flt and linux-headers, and I've started working on
>      converting
>      gcc (which is the most complicated piece of the puzzle).
> 
>  (2) Once this conversion is done, I intend to work on adding
>  (e)glibc
>      support to the internal toolchain backend, so that regardless of
>      what happens with the Crosstool-NG backend, Buildroot will
>      continue to have the possibility to build a (e)glibc toolchain.
> 
> (1) and (2) represent a significant amount of work, so don't expect
> those things to be ready overnight.
> 

ok, thanks for the news, I was a bit worried that we had would have no 
support for self-compiled glibc toolchain at some point (that was the 
main reason I was using ct-ng)
Peter Korsgaard - May 7, 2013, 9:02 p.m.
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 Yann> From: "Yann E. MORIN" <yann.morin.1998@free.fr>
 Yann> For the following reasons:
 Yann>   - it used to be broken without anyone noticing for a long time,
 Yann>   - it is still not fully integrated within the Buildroot set of options,
 Yann>   - it has not gained much traction (not even I use it),
 Yann>   - I've always argued that sustained development should use an external
 Yann>     toolchain, and not rely on building one with Buildroot,
 Yann>   - I did not submit any of the enhancements requested during the last
 Yann>     developpers' day in Brussels,
 Yann>   - I have neither the incentive nor the time to maintain and enhance it,

 Yann> it is time to deprecate the crosstool-NG backend for the 2013.05 release.

 Yann> Then, it will be entirely removed early in the 2013.08 cycle, to let some
 Yann> time for those that rely on it to voice their opinions. ;-)

Committed, thanks.

Patch

diff --git a/toolchain/Config.in b/toolchain/Config.in
index e6a3b25..665618c 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -22,6 +22,7 @@  config BR2_TOOLCHAIN_EXTERNAL
 
 config BR2_TOOLCHAIN_CTNG
 	bool "Crosstool-NG toolchain"
+	depends on BR2_DEPRECATED
 	depends on !BR2_microblaze && !BR2_aarch64 && !BR2_xtensa && !BR2_arc
 	select BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS
 	help