[Buildroot] Open question: remove "toolchain on target" option

[Buildroot] Open question: remove "toolchain on target" option

[Thomas Petazzoni]

Hello,

Today, I'd like to open the debate of the "toolchain on target"
configuration option. This option normally allows to install
binutils/gcc, and together with "install development files on target",
should allow to have a complete development environment on the target.

However, I see a number of problems with this:

 (1) A large number of first time users try to use this, and fall into
     problems, because this feature is mostly unmaintained. This gives
     a poor image of Buildroot's quality.

 (2) A large number of first time users try to use this, because they
     misunderstand what Buildroot is (a cross-compilation environment)
     and they try to use it for something that nobody amongst the core
     Buildroot developers is doing, and therefore is poorly supported.

 (3) None of the core Buildroot developers seem to care about this,
     no-one is apparently using/fixing this mechanism.

So, rather than having a bad and dysfunctional mechanism to have a
toolchain on the target, I would suggest that we simply get rid of it.
Of course, I am not going to take the decision alone, Peter will have
to do it, but I wanted to start the discussion around this topic and
gather opinions from people in the community.

Thoughts?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Open question: remove "toolchain on target" option

[Richard Braun]

On Sat, Aug 11, 2012 at 08:21:14PM +0200, Thomas Petazzoni wrote:
> So, rather than having a bad and dysfunctional mechanism to have a
> toolchain on the target, I would suggest that we simply get rid of it.
> Of course, I am not going to take the decision alone, Peter will have
> to do it, but I wanted to start the discussion around this topic and
> gather opinions from people in the community.

As a regular buildroot user (only), I think it's a wise choice, for all
the reasons you mentioned which seem quite obvious, and which are
probably why I personally never tried that.

-- 
Richard Braun

[Buildroot] Open question: remove "toolchain on target" option

[Michael S. Zick]

On Sat August 11 2012, Thomas Petazzoni wrote:
> ?(3) None of the core Buildroot developers seem to care about this,
> ? ? ?no-one is apparently using/fixing this mechanism.
> 

The only reason I can see in the argument against continuing support.

A target native toolchain is one of the most often required set of
applications in the after-market embedded world.

But since the active developers don't work in that world . . .

Mike

[Buildroot] Open question: remove "toolchain on target" option

[Thomas Petazzoni]

Hello Michael,

Le Sat, 11 Aug 2012 14:46:53 -0500,
"Michael S. Zick" <minimod@morethan.org> a ?crit :

> On Sat August 11 2012, Thomas Petazzoni wrote:
> > ?(3) None of the core Buildroot developers seem to care about this,
> > ? ? ?no-one is apparently using/fixing this mechanism.
> 
> The only reason I can see in the argument against continuing support.
> 
> A target native toolchain is one of the most often required set of
> applications in the after-market embedded world.

What do you call the "after-market embedded world"? Do you mean the
usage of consumer electronic devices for things that go beyond their
original purposes, by hobbyists? If it's the case, then I think we
definitely want to support this use case, but I don't see how this use
case requires a toolchain on the target.

Could you expand a bit on what this use case is, and how it requires
having a toolchain on the target?

Somehow, your e-mail seems to convey some sort of frustration about
Buildroot and/or its developers. What are the problems you are having?
I am really interested in understanding for what reasons Buildroot is
making people unhappy, and see if there are ways to improve that.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Open question: remove "toolchain on target" option

[Jonathan Liu]

A toolchain on the target is useful when you want to develop small 
libraries/applications/tests on the embedded device that you're 
targeting without having to think as much about cross compiling. The 
embedded device may be sufficiently powerful to do native development on 
in this case. If the option worked with external ctng toolchains I'd 
probably use it.

Regards,
Jonathan

[Buildroot] Open question: remove "toolchain on target" option

[Charles Krinke]

Are we asking for votes on this issue? If so, then my vote is No, we dont
need this feature for embedded designs.

Charles
On Aug 11, 2012 10:10 PM, "Jonathan Liu" <net147@gmail.com> wrote:

> A toolchain on the target is useful when you want to develop small
> libraries/applications/tests on the embedded device that you're targeting
> without having to think as much about cross compiling. The embedded device
> may be sufficiently powerful to do native development on in this case. If
> the option worked with external ctng toolchains I'd probably use it.
>
> Regards,
> Jonathan
>
> ______________________________**_________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/**mailman/listinfo/buildroot<http://lists.busybox.net/mailman/listinfo/buildroot>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120811/b1ff2c4a/attachment-0001.html>

[Buildroot] Open question: remove "toolchain on target" option

[Michael S. Zick]

On Sat August 11 2012, Thomas Petazzoni wrote:
> So, rather than having a bad and dysfunctional mechanism to have a
> toolchain on the target, I would suggest that we simply get rid of it.
> 

I think slowly but have had a few days to consider this Open Question.

Let me see if I can make a proposal that will encompass both of our
opinions.

To re-cap:
Once upon a time, it was decided that crosstool-ng be integrated with
Buildroot with the eventual goal of making it the replacement for the
internal BR toolchain generation.

Time passes (over a year now if memory serves) and the integration of
crosstool-ng is in a well developed state.

crosstool-ng was never intended to do Canadian Cross toolchain builds.

The (old) BR toolchain generation can only create uClibc based toolchains.

To complete that long-ago set project development goal means dropping the
(old) BR toolchain generation.
Which means, as a side effect, dropping the ability to generate a native
toolchain for the target (the (old) internal toolchain generator is the
only one that can do something like a Canadian Cross).

For this proposal, I'll ignore bit-rot, bit-rot "just happens" to everything.

Moving forward:

To reach the goal set of only having one "internal" toolchain generator 
(crosstool-ng integrated) -
Pull the dysfunctional (old) toolchain generator.

That takes care of T.P.'s suggestion above and the project's development goal.

Which leaves me and others without any target native toolchain generation. . . .

There are basically two ways to address that lack;

Add the external toolchain components as "packages" ;

Add an external CanadianCross-ng build support, as crosstool-ng once was,
prior to its integration.

At first glance, it might seem that the first path is the shorter one, until
you start to consider some of the problem details.
Just forget I mentioned choice #1 above.  ;)

I make my suggestion the choice #2 above - an external "CanadianCross-ng"
build system add-on, called from BR with BR variables.

Although the larger, up front, development path (without any interested
developers at the moment), I think over the long term it will be the less
work to maintain.  Also would be more practical to support other than uClibc
based, native toolchain builds.

A for instance, some current "corner cases" -
The oldest BR supported gcc (4.2) is too old to build glibc ;

Some build paths for the external libraries required for (optional now) gcc
options (equation solving and optimization) lead you into requiring C++ ;

I have yet to get those packages to build against uClibc++, even in a native
(ARMel) environment, let alone in a CanadianCross environment.
(Of course, that might be "operator error" at my keyboard.)

There might be better examples than the ones I give above in support of an
external "CanadianCross-ng" builder but the point remains - the build 
considerations would be more easily met by an external package than by
internal package defines.

Mikez

[Buildroot] Open question: remove "toolchain on target" option

[Alex Bradbury]

On 15 August 2012 10:56, Michael S. Zick <minimod@morethan.org> wrote:
> crosstool-ng was never intended to do Canadian Cross toolchain builds.

I don't follow crosstool-ng closely, but according to
http://crosstool-ng.org/#canadian_build

"NOTE: There is support for building canadian-crosses right now. It's
not perfect, some cleanups have to be done, but it works quite OK."

Alex

[Buildroot] Open question: remove "toolchain on target" option

[Yann E. MORIN]

Michael, All,

On Wednesday 15 August 2012 11:56:00 Michael S. Zick wrote:
> To re-cap:
> Once upon a time, it was decided that crosstool-ng be integrated with
> Buildroot with the eventual goal of making it the replacement for the
> internal BR toolchain generation.
> 
> Time passes (over a year now if memory serves) and the integration of
> crosstool-ng is in a well developed state.

There still are small issues to overcome before it can replace the
internal backend.

> crosstool-ng was never intended to do Canadian Cross toolchain builds.

Yes it was. But note that what Thomas suggests is to remove the "native
toolchain on target" (aka cross-native), which is not a canadian cross:
  - canadian:     build ? host ? target
  - cross-native: build ? host = target

crosstool-NG can do canadian-cross, but not (yet) cross-native.

> The (old) BR toolchain generation can only create uClibc based toolchains.
> 
> To complete that long-ago set project development goal means dropping the
> (old) BR toolchain generation.

See above, not completely ready.

> Which means, as a side effect, dropping the ability to generate a native
> toolchain for the target (the (old) internal toolchain generator is the
> only one that can do something like a Canadian Cross).

Nope, that's not a canadian-cross.

> For this proposal, I'll ignore bit-rot, bit-rot "just happens" to everything.
> 
> Moving forward:
[--SNIP--]
> Add an external CanadianCross-ng build support, as crosstool-ng once was,
> prior to its integration.

I'm not sure I understood that sentence...
Maybe, the solution would be to add the cross-native suport to ct-ng.

For the records, in the crosstool-NG menuconfig, you'll see that choice:

  Toolchain options  --->
    Type (Cross)  --->
      ( ) Native       (NO CODE!) (EXPERIMENTAL)
      (X) Cross
      ( ) Cross-native (NO CODE!) (EXPERIMENTAL)
      ( ) Canadian     (EXPERIMENTAL)

So, it is provisioned that ct-ng can do a cross-native, which is what
buildroot calls "native toolchain on target". Just that I did not have
the pressing need for such a toolchain, and that I did not have free
time to do it, and that no one submitted any patch. ;-)

Ultimately, that would be nice to have at least cross-native supported
(native is not that important, I think). But it will require some changes
wrt how sysroot is handled in ct-ng: a native toolchain is *not* sysrooted.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'