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

List:       busybox
Subject:    Re: question on development tree
From:       Rob Landley <rob () landley ! net>
Date:       2006-01-26 15:26:08
Message-ID: 200601260926.08422.rob () landley ! net
[Download RAW message or body]

On Thursday 26 January 2006 02:54, Bernhard Fischer wrote:
> On Wed, Jan 25, 2006 at 06:31:20PM -0600, Kumar Gala wrote:
> >On Jan 25, 2006, at 3:55 PM, Rob Landley wrote:
> >>On Tuesday 24 January 2006 13:43, Kumar Gala wrote:
> >>From what I can tell it appears that 1.1.1 work is being done on
> >>
> >>>the trunk
> >>>of the subversion tree.  Is this correct?  If not how/where is 1.1.1
> >>>development being done.
> >>
> >>It's pretty much being done in the trunk of the development tree.
> >>You know
> >>how 2.6 isn't forking off a -devel branch?  What's in the tree has
> >>to _work_,
> >>and if it doesn't work we have to _fix_ it.
> >
> >Gotcha, I didn't see a tag or anything similar for the 1.1.0
> >release.  Do you know what SVN revision matches 1.1.0?
>
> -r 13236

That was the test I told people to test.

Do a diff for 13254 and look at mdev.c out of the tarball.  I'm pretty sure 
that's the last one that made it in.

> >>The fixes that already went into mdev are good.  Vladimir checked
> >>in dnsd and
> >>fixed some of the bugs from the bug list.  Several new applets went
> >>in, but
> >>new applets shouldn't break existing stuff.  (Might shuffle some
> >>stuff into
> >>the debugging menu in menuconfig, like the libbb.so stuff there's
> >>no use case
>
> Rob, as said, there is a use-case for this, which is busybox itself.

And the advantage that it has for busybox is...?

It just seems kinda weird to me to put in the extra effort to design one 
monolithic executable implementing dozens of applets, and then split the 
monolithic version into two files and require _both_ of them to run any 
applet.  I can see that use for testing the library, but what possible 
advantage could it have for deployment?  (Unless you're trying to encourage 
out-of-tree users to use an undocumented and not guaranteed stable, 
GPL-not-LGPL api...?)

Maybe there's an advantage I don't know about, and I'm just not seeing it.  
Something to do with nommu systems that can have one instance of library code 
but duplicate executable instances?  (Are there any?)

> As already noted, i'd prefer to leave the config option in the "build
> options" menu where it is now as it seems more logical to me to look for
> it there.

Not quite caught up on the list at the moment.  (The whole moving thing.)  I'm 
a couple days behind, and what I tried to catch up on last night was sleep.  
The night before that it was laundry.

At the very least I think we should filter CONFIG_FEATURE_SHARED_BUSYBOX out 
of allyesconfig, for the same reason static linking is filtered out.  I hope 
to get the "make standalone" functionality in shortly after 1.1.1, at which 
point static, dynamic, and individual may become a choice menu.  (Then again, 
somebody may want statically linked standalone applets, so that'll need some 
more thought...)

And I'm starting to think that allyesconfig is misnamed.  What we want is sort 
of "the maximum reasonable configuration".  Is anybody actually using 
defconfig for anything?  Possibly what we want to do is turn defconfig into 
"allyesconfig" minus the things that people should explicitly ask for if they 
really want them.  (Allnoconfig doesn't have this problem.))  A way to easily 
switch off entire menus in menuconfig would be nice, though...

Never a shortage of to-do items...

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
_______________________________________________
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]