Re: another proposed crosstool project

["Robert P. J. Day" <rpjday at mindspring dot com>]

On Sun, 6 May 2007, David Kahn wrote:

> Robert P. J. Day wrote:
>
> > fair enough, but i did say that i was coming at it from the other
> > direction from crosstool and ct-ng -- while those versions give you
> > all sorts of configuration freedom, i'm trying to identify the
> > absolute *minimal* amount of work it takes to build a regular, working
> > toolchain that works for 98% (?) of the people.  (not to mention that
> > this is a reasonably educational thing to do since it makes it clear
> > what happens at each step.)
>
> How are you arriving at that 98% statistic? :)

like all statistics, i made it up, of course.  :-)

but seriously, when the majority of people initially tackle building a
toolchain, the first thing they want to see is something that just
works to cross-compile "hello, world".  in a lot of ways, that's a
major accomplishment.

once you have that, then you can start tweaking and getting fancy.
all i'm trying to do is get to that "hello, world" stage.  and, more
importantly, the mini-ct script i have now makes it *way* easier to
see what's happening underneath at each step.

it's tough to follow the actual logic in crosstool and ct-ng just
because those packages are so general and configurable.  what i'm
trying to isolate here is just what has to be done, and what
*minimally* should just work.

as an example, consider just the very first step -- where to get the
kernel headers from.  ct-ng gives you a number of choices:

  1) output from "make headers_isntall"
  2) the sanitized headers
  3) pure kernel headers
  4) your own custom directory

beginners might not appreciate the differences here, or know what the
best choice is.  in mini-ct, i want to use the output from "make
headers_install" from a recent kernel tree.  period.  because that
should just *work*.  sometimes, giving users too many choices makes
the job harder, not easier, because they're nervous about making the
wrong choice.  and the reason i posted about that was to essentially
ask, "is there any reason using *that* set of kernel headers shouldn't
work?"

in the case of the kernel headers, i'll make that choice for the user
to take that complication out of their hands, and that's why i asked
about it here -- can anyone think why that would be a *bad* choice
that would lead to failure?

and so on.  i posted the recipe for building binutils to ask the same
question -- is there any reason that *that* recipe shouldn't work?
and so it goes.

i'm not trying to create a solution for everyone.  i'm just trying to
find the simplest possible combination that works for *most* people.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

--
For unsubscribe information see http://sourceware.org/lists.html#faq