[Buildroot] Deprecate the support for toolchain on the target

[Buildroot] Deprecate the support for toolchain on the target

[Thomas Petazzoni]

The following changes since commit 234fe4433489bca81b79311239569525cc008d9d:

  perl: build with perlcross instead of qemu (2012-11-09 10:04:31 +0100)

are available in the git repository at:

  git://git.free-electrons.com/users/thomas-petazzoni/buildroot.git no-target-toolchain

for you to fetch changes up to c42b5a3ae08ae07779a6ee389a8367318efe96bf:

  Mark a number of development related packages as deprecated (2012-11-10 23:34:39 +0100)

----------------------------------------------------------------
Thomas Petazzoni (2):
      Deprecate the support for the toolchain on target
      Mark a number of development related packages as deprecated

 Config.in                  |    4 ++++
 package/autoconf/Config.in |    3 +++
 package/automake/Config.in |    3 +++
 package/libtool/Config.in  |    2 ++
 package/make/Config.in     |    2 ++
 toolchain/gcc/Config.in.2  |    5 ++---
 6 files changed, 16 insertions(+), 3 deletions(-)

Thanks,
-- 
Thomas Petazzoni

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

[Thomas Petazzoni]

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(-)

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
-- 
1.7.9.5

[Buildroot] [PATCH 2/2] Mark a number of development related packages as deprecated

[Thomas Petazzoni]

automake, autoconf, libtool and make on the target are basically
useless if we don't support building a toolchain on the target. Of
course, the host variant of automake, autoconf and libtool will remain
available.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/autoconf/Config.in |    3 +++
 package/automake/Config.in |    3 +++
 package/libtool/Config.in  |    2 ++
 package/make/Config.in     |    2 ++
 4 files changed, 10 insertions(+)

diff --git a/package/autoconf/Config.in b/package/autoconf/Config.in
index c304572..9302f50 100644
--- a/package/autoconf/Config.in
+++ b/package/autoconf/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_AUTOCONF
 	bool "autoconf"
 	depends on !(BR2_avr32 || BR2_bfin || BR2_sh2 || BR2_sh2a || BR2_sh3 || BR2_sh3eb || BR2_sh64)
+	# We no longer support a toolchain on the target
+	depends on BR2_DEPRECATED
 	select BR2_PACKAGE_PERL
 	help
 	  Extensible program for developing configure scripts.  These
@@ -10,3 +12,4 @@ config BR2_PACKAGE_AUTOCONF
 
 comment "autoconf requires an architecture supported by qemu"
 	depends on BR2_avr32 || BR2_bfin || BR2_sh2 || BR2_sh2a || BR2_sh3 || BR2_sh3eb || BR2_sh64
+	depends on BR2_DEPRECATED
diff --git a/package/automake/Config.in b/package/automake/Config.in
index f8d74ef..924b29c 100644
--- a/package/automake/Config.in
+++ b/package/automake/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_AUTOMAKE
 	bool "automake"
 	depends on !(BR2_avr32 || BR2_bfin || BR2_sh2 || BR2_sh2a || BR2_sh3 || BR2_sh3eb || BR2_sh64)
+	# We no longer support a toolchain on the target
+	depends on BR2_DEPRECATED
 	select BR2_PACKAGE_AUTOCONF
 	select BR2_PACKAGE_PERL
 	help
@@ -11,3 +13,4 @@ config BR2_PACKAGE_AUTOMAKE
 
 comment "automake requires an architecture supported by qemu"
 	depends on BR2_avr32 || BR2_bfin || BR2_sh2 || BR2_sh2a || BR2_sh3 || BR2_sh3eb || BR2_sh64
+	depends on BR2_DEPRECATED
diff --git a/package/libtool/Config.in b/package/libtool/Config.in
index d3cf2d7..42df25b 100644
--- a/package/libtool/Config.in
+++ b/package/libtool/Config.in
@@ -1,5 +1,7 @@
 config BR2_PACKAGE_LIBTOOL
 	bool "libtool"
+	# We no longer support a toolchain on the target
+	depends on BR2_DEPRECATED
 	help
 	  Library that hides the complexity of using shared/static libraries
 	  on different platforms behind a consistent, portable interface.
diff --git a/package/make/Config.in b/package/make/Config.in
index ea2ae1b..e5cc970 100644
--- a/package/make/Config.in
+++ b/package/make/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_MAKE
 	bool "make"
 	select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT_IF_LOCALE
+	# We no longer support a toolchain on the target
+	depends on BR2_DEPRECATED
 	help
 	  A tool which controls the generation of executables and other
 	  non-source files of a program from the program's source files.
-- 
1.7.9.5

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

[Alex Bradbury]

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

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

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

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

[Arnout Vandecappelle]

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
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 2/2] Mark a number of development related packages as deprecated

[Arnout Vandecappelle]

On 11/10/12 23:36, Thomas Petazzoni wrote:
> automake, autoconf, libtool and make on the target are basically
> useless if we don't support building a toolchain on the target. Of
> course, the host variant of automake, autoconf and libtool will remain
> available.
>
> Signed-off-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>

Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

  Still for 2012.11 please :-)

  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

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

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

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

[Arnout Vandecappelle]

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
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

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

[Peter Korsgaard]

>>>>> "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.

-- 
Bye, Peter Korsgaard

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

[Peter Korsgaard]

>>>>> "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.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 2/2] Mark a number of development related packages as deprecated

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> automake, autoconf, libtool and make on the target are basically
 Thomas> useless if we don't support building a toolchain on the target. Of
 Thomas> course, the host variant of automake, autoconf and libtool will remain
 Thomas> available.

Committed with some fixups to apply after the perl/qemu changes.

-- 
Bye, Peter Korsgaard

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

[Gustavo Zacarias]

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.

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

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com