[PATCH 00/39] Windows port, base and archival/

[Mike Frysinger]

On Saturday 24 April 2010 19:43:17 Rob Landley wrote:
> On Tuesday 20 April 2010 16:48:16 Mike Frysinger wrote:
> > > > this is a ton of duplicate crap and exactly why i suggested we look
> > > > at integrating something like gnulib/ for portability.  busybox
> > > > shouldnt be wasting any time at all on this.
> > > 
> > > How about a subproject for the above stuff? We can get rid of them
> > > easily once something like gnulib is intergrated.
> > 
> > how about we integrate gnulib now and then we dont need a subproject.
> > subprojects take time to setup, integrate, and then break down.
> 
> Wait...
> 
> You're proposing taking
> 
> 1) a "layer of indirection" library

obviously any portability project is going to need this

> 2) from the GNU project

irrelevant

> 3) which is incompatably licensed under GPLv3 (when we took GPLv2 code from
> kernel developers years ago in a bunch of places)...

if you actually understood gnulib, you know that individual modules have 
individual licenses and are designed to be cherry picked

> You think block copying gnu code into busybox is a good idea:
> 
> http://www.gnu.org/software/gnulib/manual/gnulib.html#Library-vs-Reusable-C
> ode
> 
> > Classical libraries are installed as binary object code. Gnulib is
> > different: It is used as a source code library. Each package that uses
> > Gnulib thus ships with part of the Gnulib source code. The used portion
> > of Gnulib is tailored to the package: A build tool, called gnulib-tool,
> > is provided that copies a tailored subset of Gnulib into the package.
> 
> This package is a neat summary of everything BusyBox has ever stood in
> opposition to.  We eliminate layers of indirection, we take total ownership
> of our implementation down to libc (or sometimes even system calls) so
> that we can rip it apart and shuffle it up to shave another 5% off as
> often as possible...  And the gnu guys do that instead.

you cant have it both ways.  either busybox replicates what gnulib is doing 
and wastes time on nothing useful, or people *optionally* use appropriate 
gnulib modules when the target in question sucks (i.e. mingw), or busybox 
doesnt support any of these systems.

i dont care about supporting mingw or any other non-Linux target, but i do 
care about integrating/maintaining cruft that distracts from busybox's 
purpose.  gnulib satisfies the people who want to use it on other systems 
while minimally distracting people who dont care.

> I'd consider the proposal for integrating that into busybox to be a troll
> of epic proportions, except this being Mike I expect that's an honest
> reflection of his judgement about what a good idea looks like.

*yawn*
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20100425/819463bc/attachment.pgp>