New CONFIG_ guard: IF_FEATURE_BLAH(stuff)

[Rob Landley]

On Wednesday 08 February 2006 14:55, Bernhard Fischer wrote:

> >  opt = bb_getopt_ulflags(argc, argv, "Rs:ud:r:"
> > IF_FEATURE_DATE_ISOFMT("I::"),
> > &date_str, &date_str, &filename
> > IF_FEATURE_DATE_ISOFMT(,&isofmt_arg) );
> >
> >Opinions?
>
> Sounds ok to me. Look at pidof.c where i did that "manually", so if we
> can have this generated, the better. Looking at pidof, perhaps it would
> make sense to reuse the value of the IF_BLAH (or ENABLE as it's
> currently named) for the shifts as it would eventually make the defined
> a bit more readable.
>
> Should we just rename the defines in include/_usage.h to start with IF
> instead of USAGE? I guess that would be the simplest way to do.

I noticed that about five minutes ago.  I don't mind the USAGE_ name, and if 
that's what we're already using there's no reason to change it.

There's also no need for a separate _usage.h file, since the sed invocation 
that generates the ENABLE_ guards can trivially add USAGE_ guards, ala (minus 
the wordwrap mangling):

include/bb_config.h: include/config.h
        @echo -e "#ifndef BB_CONFIG_H\n#define BB_CONFIG_H" > $@
        @sed -e 's/#undef CONFIG_\(.*\)/#define ENABLE_\1 0\n#define USAGE_\1
(x)/' \
            -e 's/#define CONFIG_\(.*\) 1/#define CONFIG_\1 1\n#define 
ENABLE_\1 1\n#define USAGE_\1(x) x/' \
                < $< >> $@
        @echo "#endif" >> $@

The problem is, when I do that bb_mkdep.c barfs:

landley at driftwood:~/busybox/busybox$ make
  GEN .depend
/home/landley/busybox/busybox/include/bb_config.h:18 hmm, unexpected function 
macro
make[1]: *** [.depend] Error 1

It's so brittle that if you move the same data from one file to another, it 
can't cope.

I looked or that error message in the bb_mkdep.c source code, and on line 376 
I found it buried in a lot of yacc & lex output.  Where the yacc source is, I 
have no idea...

> To try this out, just change the "USAGE" string in the toplevel
> Makefile in the _usage.h rule and look at the very bottom of
> platform.h. It's all prepared for you :)

I see no reason not to just keep it as USAGE_ and use that elsewhere in the .c 
code.  (If that's the symbol we've already got doing exactly this, it just 
needs to be better documented.)

I would like to consolidate things so that the sed invocation generating 
bb_config.h also generates the USAGE_, so you only have to #include one file 
to get all the config macros, but bb_mkdep.c is so brittle that if you move 
the USAGE_ from one file to another it barfs.

I'll email Vladimir...

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.