Deprecate the support for toolchain on the target

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

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.

---
 Config.in                 |    4 ++++
 toolchain/gcc/Config.in.2 |    5 ++---
 2 files changed, 6 insertions(+), 3 deletions(-)

index 68190a5..eaafece 100644
@@ -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

index d060a80..c8a8cf6 100644
@@ -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

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

Alex,

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

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

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

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

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

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.

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

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

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.

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

index c304572..9302f50 100644
@@ -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

index f8d74ef..924b29c 100644
@@ -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

index d3cf2d7..42df25b 100644
@@ -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.

index ea2ae1b..e5cc970 100644
@@ -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

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

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