[busybox] v0.5 of busybox single-applet iterative build script

[Rob Landley]

On Thursday 22 June 2006 3:32 am, Bernhard Fischer wrote:
> On Wed, Jun 21, 2006 at 04:24:23PM -0400, Rob Landley wrote:
> >I'm actually tempted to go through and rename the applet configs
> > CONFIG_APP (I.E. CONFIG_CP -> CONFIG_APP_CP).
>
> That would be very welcome, from my POV (remember the CONFIG_TR and
> CONFIG_SYSCTL gotchas..)

I'm trying to get a release candidate out by monday so that we can have the 
week to find bugs before the final release on the 30th...

Still...  Hmmm.

> >Right now we've got CONFIG_FEATURE and CONFIG_DEBUG that our various
> >config-twiddling tools can sink their teeth into, but no easy way to go
> > "this is an applet".
> >
> >The alternative is to find everything that _isn't_ an applet and give it
> > an understandable prefix.  Your script has an interesting ignore list
> > that's a good start fo rthis.
> >
> >These don't start with "CONFIG_", and I'm thinking of moving most of them
> > out of .config anyway:
> >  HAVE_DOT_CONFIG
>
> We need some unique CONFIG_THING that is always set, so we can see if
> there is a .config and if it is non-empty. Any name does this for me.

In our case, that would probably be CONFIG_BUSYBOX. :)

> >  PREFIX
>
> This should really be CONFIG_INSTALLER_PREFIX or something alike.

This is a prefix for both "make install" and for the busybox --install 
command, right?

It would be nice if we had some kind of help command that could print out all 
the names of all our applets in an easily parseable form.  (Then the busybox 
command wouldn't have to, and the --install stuff could become a trivial 
shell script...)

./busybox help
./busybox help command
./busybox help --names
./busybox help --paths

Still working what exactly would be a good idea to do.  (For 1.3.)

> >  CROSS_COMPILER_PREFIX
>
> wipe it, the user should plain `make CROSS=/there/ia64-uclibc-´
>
> >  EXTRA_CFLAGS_OPTIONS
>
> Ditto, wipe. `make CFLAGS_EXTRA=""´ instead.

Agreed.

> >Your list also has CONFIG_DEBUG and CONFIG_FEATURE_INSTALLER which we can
> >already filter out...
> >
> >
> >That leaves:
> >  CONFIG_SHOW_USAGE
> >  CONFIG_SELINUX
> >  CONFIG_STATIC
> >  CONFIG_BUILD.*
> >  CONFIG_INSTALL_.*
> >  CONFIG_LFS
> >  CONFIG_NO_DEBUG_LIB
> >  CONFIG_DMALLOC
> >  CONFIG_EFENCE
> >  CONFIG_STRIP_BINARIES
> >  CONFIG_LOCALE_SUPPORT
> >  CONFIG_MD5_SIZE_VS_SPEED
> >  CONFIG_BUSYBOX_EXEC_PATH
> >  CONFIG_DEVFS
> >  CONFIG_VERBOSE_USAGE
> >
> >Which should possibly have FEATURE stuck in their names...?
> >
> >Hmmm...  If we're going to break people's .config files, now might be a
> > good time.  On the other hand, I hope to come up with a release candidate
> > this weekend and come out with the final 1.2.0 on the 30th...
>
> We already break peoples .config that stem from 1.0x and 1.1.x, so
> personally, i'd change them now rather than breaking them *again* from
> 1.2.x->1.3.x(or however it will be called).

Yup, that's what I was thinking.

> The USAGE .. VERBOSE_USAGE look like they are in these cathegories, fwiw:
> - build/install (build_*, install_*, installer_*, installer_prefix)
> - debug (debug_*, no_debug_lib, dmalloc, efence,
> - global settings (LFS, perhaps usage, devfs_names, selinux, locale, ..)
> - misnomers (md5_size_vs_speed, nitpick)
>
> i'd put the globals into CONFIG_BB_, applets into CONFIG_APPLET_,
> features in CONFIG_FEATURE, debug in CONFIG_BB_DBG, installer into
> CONFIG_BB_INSTALLER etc.

We already have CONFIG_FEATURE and CONFIG_DEBUG, but I don't want to make 
names too long.  (Besides, APP is ambivalent between APPLET and 
APPLICATION. :)  Globals I'll worry about later, the pressing need right now 
is a way to do things like "allbareconfig" or your script without having to 
know what lots of unrelated symbols mean.

I just converted the networking/dhcp menu since it was small.  Toe in the 
water sort of thing...

Lunchtime.

> Just a thought

Rob
-- 
Never bet against the cheap plastic solution.