Patchwork [1/2] Deprecate the support for the toolchain on target

login
register
mail settings
Submitter Thomas Petazzoni
Date Nov. 10, 2012, 10:36 p.m.
Message ID <4afe9c298939f3701caa09c2cc5c4bc04f6d4408.1352586949.git.thomas.petazzoni@free-electrons.com>
Download mbox | patch
Permalink /patch/198224/
State Accepted
Commit 8fe6efa874c535d5e8cfa05f5837bff2018b07fc
Headers show

Comments

Thomas Petazzoni - Nov. 10, 2012, 10:36 p.m.
As discussed during the ELCE 2012 Buildroot Developers Meeting, we no
longer want to support the possibility of building a toolchain for the
target. None of the core developers have any use for this, it has been
known to be broken or cause problems for a long time without anyone
providing fixes for it.

In addition to this, Buildroot is inherently a cross-compilation tool,
so the usage of a native toolchain on the target is not really
useful. Many newcomers are tempted to use this possibility even though
it is clearly not the intended usage of Buildroot.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 Config.in                 |    4 ++++
 toolchain/gcc/Config.in.2 |    5 ++---
 2 files changed, 6 insertions(+), 3 deletions(-)
Alex Bradbury - Nov. 10, 2012, 11:26 p.m.
On 10 November 2012 22:36, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> As discussed during the ELCE 2012 Buildroot Developers Meeting, we no
> longer want to support the possibility of building a toolchain for the
> target. None of the core developers have any use for this, it has been
> known to be broken or cause problems for a long time without anyone
> providing fixes for it.
>
> In addition to this, Buildroot is inherently a cross-compilation tool,
> so the usage of a native toolchain on the target is not really
> useful. Many newcomers are tempted to use this possibility even though
> it is clearly not the intended usage of Buildroot.

If someone took lead on reintroducing this functionality would it be
accepted? There are at least a couple of cases where installing
development files are useful:
* When using buildroot to build a rootfs that is used as a sysroot for
an external build system
* When using e.g. luajit packages which can make use of header files
to generate bindings (not exploited all that much right now due to
lack of preprocessor support in luajit)

Not disagreeing with this being marked deprecated for the time being
at all, I'm just not so sure that devfiles or event native toolchains
are inherently out of the scope of buildroot.

Alex
Thomas Petazzoni - Nov. 11, 2012, 10:09 p.m.
Alex,

On Sat, 10 Nov 2012 23:26:19 +0000, Alex Bradbury wrote:

> If someone took lead on reintroducing this functionality would it be
> accepted? There are at least a couple of cases where installing
> development files are useful:
> * When using buildroot to build a rootfs that is used as a sysroot for
> an external build system

To build a sysroot containing a cross-compiler + header files and
libraries you don't need the support for the toolchain on target.

> * When using e.g. luajit packages which can make use of header files
> to generate bindings (not exploited all that much right now due to
> lack of preprocessor support in luajit)

What do you need the toolchain on target for this? Header files are
available in the toolchain sysroot, i.e in
output/host/usr/<arch-tuple>/sysroot/.

So unless I'm wrong, none of those use-cases require a toolchain on the
target. Or maybe you could provide more details about those use cases
to convince us that having a toolchain on the target is important?

Best regards,

Thomas
Arnout Vandecappelle - Nov. 11, 2012, 10:53 p.m.
On 11/10/12 23:36, Thomas Petazzoni wrote:
>   config BR2_HAVE_DOCUMENTATION
>   	bool "documentation on the target"
> +	# We no longer want to support a toolchain on the target
> +	depends on BR2_DEPRECATED
>   	help
>   	  Install the documentation, including manual pages and info
>   	  pages, on the target.

  Who, documentation has nothing to do with the toolchain on target!  I can
easily imagine use cases where you want to be able to do 'man tcpdump' on
the target.

  Regards,
  Arnout
Thomas Petazzoni - Nov. 11, 2012, 10:59 p.m.
On Sun, 11 Nov 2012 23:53:33 +0100, Arnout Vandecappelle wrote:

>   Who, documentation has nothing to do with the toolchain on target!
> I can easily imagine use cases where you want to be able to do 'man
> tcpdump' on the target.

Well this is what we agreed during the meeting, and is even noted in
your Action Points at
http://elinux.org/Buildroot:DeveloperDaysELCE2012#Action_points :-)

Best regards,

Thomas
Arnout Vandecappelle - Nov. 11, 2012, 11:52 p.m.
On 11/11/12 23:59, Thomas Petazzoni wrote:
>
> On Sun, 11 Nov 2012 23:53:33 +0100, Arnout Vandecappelle wrote:
>
>>    Who, documentation has nothing to do with the toolchain on target!
>> I can easily imagine use cases where you want to be able to do 'man
>> tcpdump' on the target.
>
> Well this is what we agreed during the meeting, and is even noted in
> your Action Points at
> http://elinux.org/Buildroot:DeveloperDaysELCE2012#Action_points :-)

  Right.  Typing turns of your brain, to some extent :-)

  Regards,
  Arnout
Peter Korsgaard - Nov. 17, 2012, 8:21 a.m.
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

 >>> Who, documentation has nothing to do with the toolchain on target!
 >>> I can easily imagine use cases where you want to be able to do 'man
 >>> tcpdump' on the target.
 >> 
 >> Well this is what we agreed during the meeting, and is even noted in
 >> your Action Points at
 >> http://elinux.org/Buildroot:DeveloperDaysELCE2012#Action_points :-)

 Arnout>  Right.  Typing turns of your brain, to some extent :-)

On the other hand, documentation on the target doesn't have the same
problems as toolchain, so if people do use it, I don't have a problem
keeping it.

I've never personally used it though.
Peter Korsgaard - Nov. 17, 2012, 8:22 a.m.
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> As discussed during the ELCE 2012 Buildroot Developers Meeting, we no
 Thomas> longer want to support the possibility of building a toolchain for the
 Thomas> target. None of the core developers have any use for this, it has been
 Thomas> known to be broken or cause problems for a long time without anyone
 Thomas> providing fixes for it.

 Thomas> In addition to this, Buildroot is inherently a cross-compilation tool,
 Thomas> so the usage of a native toolchain on the target is not really
 Thomas> useful. Many newcomers are tempted to use this possibility even though
 Thomas> it is clearly not the intended usage of Buildroot.

Committed, thanks.
Gustavo Zacarias - Nov. 17, 2012, 10:42 a.m.
On 11/17/2012 05:21 AM, Peter Korsgaard wrote:
> On the other hand, documentation on the target doesn't have the same
> problems as toolchain, so if people do use it, I don't have a problem
> keeping it.
> 
> I've never personally used it though.

On a related note there's no man-pages so the documentation is always
kind of incomplete. There's no man package either, though busybox has one.
And i don't recall anyone asking where man-pages is :)
But it's a no brainer, it doesn't cause any significant overhead.
Personally i've never used it either.
Regards.
Thomas Petazzoni - Nov. 17, 2012, 11:06 a.m.
On Sat, 17 Nov 2012 07:42:36 -0300, Gustavo Zacarias wrote:
> On 11/17/2012 05:21 AM, Peter Korsgaard wrote:
> > On the other hand, documentation on the target doesn't have the same
> > problems as toolchain, so if people do use it, I don't have a problem
> > keeping it.
> > 
> > I've never personally used it though.
> 
> On a related note there's no man-pages so the documentation is always
> kind of incomplete. There's no man package either, though busybox has one.
> And i don't recall anyone asking where man-pages is :)
> But it's a no brainer, it doesn't cause any significant overhead.
> Personally i've never used it either.

I also never use it, and I think that many packages do not install
their documentation, so it's most likely very incomplete.

Best regards,

Thomas

Patch

diff --git a/Config.in b/Config.in
index 68190a5..eaafece 100644
--- a/Config.in
+++ b/Config.in
@@ -393,6 +393,8 @@  config BR2_PREFER_STATIC_LIB
 
 config BR2_HAVE_DOCUMENTATION
 	bool "documentation on the target"
+	# We no longer want to support a toolchain on the target
+	depends on BR2_DEPRECATED
 	help
 	  Install the documentation, including manual pages and info
 	  pages, on the target.
@@ -401,6 +403,8 @@  config BR2_HAVE_DOCUMENTATION
 
 config BR2_HAVE_DEVFILES
 	bool "development files in target filesystem"
+	# We no longer want to support a toolchain on the target
+	depends on BR2_DEPRECATED
 	help
 	  Install headers and static libraries in the
 	  target filesystem
diff --git a/toolchain/gcc/Config.in.2 b/toolchain/gcc/Config.in.2
index d060a80..c8a8cf6 100644
--- a/toolchain/gcc/Config.in.2
+++ b/toolchain/gcc/Config.in.2
@@ -1,5 +1,7 @@ 
 config BR2_PACKAGE_GCC_TARGET
 	bool "gcc"
+	# We no longer want to support a toolchain on the target
+	depends on BR2_DEPRECATED
 	depends on BR2_HAVE_DEVFILES && BR2_TOOLCHAIN_BUILDROOT
 	select BR2_PACKAGE_BINUTILS
 	select BR2_PACKAGE_BINUTILS_TARGET
@@ -30,6 +32,3 @@  config BR2_EXTRA_TARGET_GCC_CONFIG_OPTIONS
 	  Any additional target gcc options you may want to include....
 	  Including, but not limited to --disable-checking etc.
 	  Refer to */configure in your gcc sources.
-
-comment "gcc needs development files in target filesystem"
-	depends on !BR2_HAVE_DEVFILES && BR2_TOOLCHAIN_BUILDROOT