[patch] merge mtab_file.c into messages.c and provide fstab_file

[Rob Landley]

On Friday 31 March 2006 3:34 pm, Bernhard Fischer wrote:
> >> Objections or comments?
> >
> >-LIBBB_MOBJ0:=$(patsubst %,$(LIBBB_DIR)/%, $(LIBBB_MOBJ0))
> >-$(LIBBB_MOBJ0):$(LIBBB_MSRC0)
> >+LIBBB_MOBJ0-$(CONFIG_FSCK)     += fstab_file.o
> >+LIBBB_MOBJ0-$(CONFIG_MOUNT)    += fstab_file.o
> >+LIBBB_MOBJ0-$(CONFIG_SWAPONOFF)        += fstab_file.o
> >+LIBBB_MOBJ0-$(CONFIG_DF)       += mtab_file.o
> >+LIBBB_MOBJ0-$(CONFIG_EJECT)    += mtab_file.o
> >+LIBBB_MOBJ0-$(CONFIG_MOUNT)    += mtab_file.o
> >+LIBBB_MOBJ0-$(CONFIG_UMOUNT)   += mtab_file.o
> >+LIBBB_MOBJ0-y:=$(patsubst %,$(LIBBB_DIR)/%,$(sort $(LIBBB_MOBJ0-y)))
> >+$(LIBBB_MOBJ0-y):$(LIBBB_MSRC0)
> >        $(compile.c) -DL_$(notdir $*)
> >
> >Ok, I see that turning into exponential complexity really, really fast. 
> > And
>
> Sigh. We can as well build it unconditionally, if you'd prefer that.

Ideally I'd like some way to easily annotate the files themselves that we can 
generate usable dependencies from automatically.  (Or just naturally detect 
that we're using it, which is harder but not impossible.)  I need to spend 
some time thinking about it, though.

For the short term, building them unconditionally but collecting them together 
so we can track what we'd like to build better dependency infrastructure for 
sounds good...

> >it's the kind that bites users because if CONFIG_EJECT doesn't have the
> > right link to mtab_file.o but we're building CONFIG_DF so it gets built
> > anyway, then we won't hit it in testing.  (The losetup thing from before,
> > only an
>
> We have that build-single-applet script which would catch stuff like
> this if people are sloppy about simply grepping for the conditional
> compiled symbol and depending on all occurances. But see below.
>
> >order of magnitude worse.)  Plus just having this kind of huge table of
> >dependencies in the CONFIG file anyway is a bit unpleasant...
> >
> >I still have the dependency generation thing I was playing with in
> > February. Maybe I can autodetect this kind of dependency?  (If all the
> > symbols that do
>
> That would be way cool. We wouldn't have to do all that stuff hardcoded in
> the Makefiles, so this would of course be well received.

But not trivial to do.  Hmmm...

Need to clear my to-do list a bit this weekend. :)

> >this kind of thing are required to have a bb_ prefix I can do a really
> > simple whole-word search on the files...)
>
> They don't currently all have bb_ prefixes, unfortunately. Let's see..
>
> I have an busybox.enforce-usage-of-libbb.diff here, which was ment to
> help people in porting new applets to use libbb. My list is
> contained also these:
>
> +ifeq ($(strip $(CONFIG_PORT_NEW_APPLET)),y)
> +# OBJ1
> +LIBBB_X_FUNCTIONS:= malloc realloc calloc
> +LIBBB_FUNCTIONS:= strlen
> +LIBBB_BB_X_FUNCTIONS:= strdup strndup fopen open read ferror
> +# OBJ2
> +LIBBB_BB_FUNCTIONS:= vfprintf fprintf printf
> +# OBJ4
> +LIBBB_SAFE_FUNCTIONS := strtoi strtod strtol
> +# OBJ
> +LIBBB_MY_FUNCTIONS:= getgrgid getgrnam getpwnam getpwuid
> +LIBBB__FUNCTIONS:= asprintf
>
>
> the my_*() are gone by now, IIRC.

Ok...

> >Or else we can use whatever markup in the files these things are generated
> >from to compile a search list.  Or force it to #include some special
> > header file that defines this symbol, or...
>
> .. extract a full list from libbb.h, look for these symbols in the
> selected applets via bb_mkdep and emit a dep for the respective .o
> files, or..

Ah, using libbb.h as a master list of things to look for is a good idea.  That 
may make things noticeably easier.  (And annotating libbb.h with strange 
symbols is _just_fine_ if it means that the annotations only have to be in 
one place...)

Basically if we can have a master list of "this is something that gets built 
from here" without needing a list of every single place that makes use of 
that, we're definitely ahead of the game...

Hmmm...

Rob
-- 
Never bet against the cheap plastic solution.