| Message ID | 4afe9c298939f3701caa09c2cc5c4bc04f6d4408.1352586949.git.thomas.petazzoni@free-electrons.com |
|---|---|
| State | Accepted |
| Commit | 8fe6efa874c535d5e8cfa05f5837bff2018b07fc |
| Headers | show |
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
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
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
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
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" == 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.
>>>>> "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.
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.
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
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
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(-)