[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: Headers including headers and precompilation
From:       Rob Landley <rob () landley ! net>
Date:       2006-03-31 23:55:08
Message-ID: 200603311855.09022.rob () landley ! net
[Download RAW message or body]

On Friday 31 March 2006 3:58 pm, Rich Felker wrote:
> On Fri, Mar 31, 2006 at 03:38:48PM -0500, Rob Landley wrote:
> > On Friday 31 March 2006 1:13 pm, Robert P. J. Day wrote:
> > > > The dependency is simple: SUSv3 and maybe Linux headers.
> > >
> > > please stop promoting this approach.  it's just plain evil.  if it was
> > > such a good idea, then the C library would come with a single header
> > > file -- clibrary.h or something.  it doesn't.  that should tell you
> > > everything you need to know.
> >
> > Yeah, that it was designed on a 16-bit machine in 1971.  Back then the
> > entire system had 64k of ram, only the first 6 characters of each
> > identifier were significant...
> >
> > You are aware of the new build-at-once mode, right?
>
> I find it utterly hypocritical that someone working on a project that
> replaces huge bloated crap with small efficient implementations is
> advocating that we should all need huge systems with lots of resources
> to be able to compile anything... Just because busybox doesn't include
> a C compiler (yet ;) doesn't mean it's justified to require massive
> gcc bloatware.

Actually I want to get it to compile via tcc too.  That compiles code about 10 
times faster than gcc does according to the benchmarks on tinycc.org, and the 
compiler itself is about 100k.  (The output's about twice the size of what 
gcc produces, though.  Its optimizer can do dead code elimination and such, 
but is nothing to write home about.)

The fun part about that one is that, in theory, we could do the same trick as 
gcc's build-at-once mode only add "-run" to the command line and tcc would 
run busybox straight from the source code. :)

This is just a for-fun project, and not any sort of priority.

The point of mentioning build at once mode is that it produces a smaller 
busybox at the expense of compile time.  This has always been a trade-off we 
were willing to at least offer as a config option.  You are agitating 
fiercely in favor of a change which would not affect the resulting binary and 
would be a net increase in the size of the source code, with no concrete 
benefits.  Whether or not it reduces complexity is purely a matter of 
opinion.  You talk about portability but the only actual comparison with 
another platform (the Cocoa API of MacOS X) was an argument against you.

I really don't care about this issue one way or the other, but I tend to lean 
against large changes with no clear benefits just because they're needless 
churn.  I also find it amusing that someone can manage to be indignant about 
the way busybox has been doing things for many years.  We're open to 
suggestions, if you can demonstrate that something is, in fact, an 
improvement.

By the way, if you can find #includes that can be _removed_ from busybox.h or 
libbb.h, and any corresponding fixups to various apps so that everything 
still builds with those #includes removed, that would at least be a case 
where we could argue the merits of _code_.

Want to try for a patch?

> Rich

Rob
-- 
Never bet against the cheap plastic solution.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]