On Thu, Aug 23, 2001 at 09:26:33PM +0200, Jes Sorensen wrote:
> >>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:
>
> Tom> On Thu, Aug 23, 2001 at 10:36:20AM -0500, Bob Glamm wrote:
> Tom> And the same set of replies. Doing it in !python would be much
> Tom> harder than it sounds. But people have stepped up and said
> Tom> they'd do it in C. So python is only needed for xconfig. And
> Tom> that's just trading tcl for python. The other thing is, the
> Tom> python cml2 tools are supposed to eliminate a bunch of other
> Tom> tools and remove some of the dependancies.
>
> Most of these tools were written in bash or C ... going the python way
> is a major loss.
Or perl.
> >> Why isn't ncurses a pain? For the same reason ncurses wasn't a
> >> pain when 'make menuconfig' (lxdialog) was introduced (yes, I did
> >> many a 'make config'): curses/ncurses was already on just about
> >> every system running Linux - it was built into the text editor.
>
> Tom> And many a new system has python.
>
> It still doesn't solve the situation of people building embedded
> systems who do only have a bare minimum on their systems. Or people
> who are bringing up systems who do not have network/floppy available
> and do not want to move their disks between systems constantly in
> order to configure their kernels. I have brought this point up
> several times to the CML2 developer and every time I received the
> utterly useless answer saying I should move my source to another box,
> configure it there and move it back to the devel box.
You've said this before. :) Just how small of an 'embedded' system are
you talking about? I know of people who do compile a kernel now and
again on a 'small' system, for fun. On a larger (cPCI) system, I
don't see your point. If you can somehow transport the 21mb[1] bzip2
kernel source to your system, you can transport python. If you're
porting to a brand new arch, there's still good tests before you
have shlib support (You've mentioned that before too I think).
> >> It does surprise me that Linus would actually allow this to happen.
> >> It's been my impression that he favors a clean, elegant solution.
> >> Maybe it's just me, but adding a dependency solely for the sake of
> >> building the kernel doesn't strike me as very clean or elegant.
>
> Tom> Because the python solution happened to fix all of the problems.
>
> And introduces new problems that so far haven't been addressed.
Which is what? The dependancy on python2?
> The solution seems to be that someone implements CML2 in C, once that
> happens we are talking something completely different.
As long as it does everything the current version does and is just as
fast I don't think there'll be much of an argument for either. Hell,
probably both for a while...
-- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:01:01 EST