Currently we have these errors:
./modutils/Config.in: No helptext for 'CONFIG_FEATURE_QUERY_MODULE_INTERFACE'
./networking/Config.in: No helptext for 'CONFIG_IPADDR'
./networking/Config.in: No helptext for 'CONFIG_IPLINK'
./networking/Config.in: No helptext for 'CONFIG_IPROUTE'
./networking/Config.in: No helptext for 'CONFIG_IPTUNNEL'
./coreutils/Config.in: No helptext for 'CONFIG_UNIX2DOS'
For each CONFIG_SYMBOL, include/bb_config.h now has both ENABLE_SYMBOL
and USE_SYMBOL(x). ENABLE_SYMBOL is still always defined (1 or 0) so that
if(ENABLE) should optimize out when it's zero. The USE_SYMBOL(X) will only
splice in X if the symbol is defined, otherwise it'll be empty.
Thus we can convert this:
#ifdef CONFIG_ARGS
opt = bb_getopt_ulflags(argc, argv, "ab:c"
#ifdef CONFIG_THINGY
"d:"
#endif
, &bvalue
#ifdef CONFIG_THINGY
, &thingy
#endif
);
#endif
into this:
if (ENABLE_ARGS) {
opt = bb_getopt_ulflags(argc, argv, "ab:c" USE_THINGY("d:"), &bvalue
USE_THINGY(, &thingy));
}
And it should produce the same code.
Unlike the old versions in include/_usage.h, the new USE_SYMBOL(x) can handle
commas in its arguments (as shown above). (The _usage.h file is obsolete and
no longer generated.)
Nobody should need to include config.h directly anymore, bb_config.h should
define all the configuration stuff we need. Someday, the CONFIG_SYMBOL
versions should go away in favor of ENABLE_SYMBOL and USE_SYMBOL().
Thanks to vodz for the new version of bb_mkdep.c that works with function
macros.
CONFIG_NUMERIC_CONSTANT=
And on reading it back in, it would complain that '' was an invalid value for
that field. I.E. "make allnoconfig && make" worked fine, but
"make allnoconfig && make menuconfig" barfed reading in the config file.
So now I have it write out "0" as the blank value. (It's initialized to the
default value when the menu becomes visible anyway; I checked.) That seems
to work.
The configure system's save function edited out sub-menus that wouldn't be
displayed in the current configuration, meaning config.h wouldn't have #udef
entries for those symbols, meaning bb_config.h would have the relevant
ENABLE_ missing instead of defined to 0. This broke the build.
So I fixed it, and then reorganized the applets.c and busybox.c to take
away the warnings this revealed (code that would be optimized out was making
calls to functions that hadn't been prototyped. So I added an #else case
to those #ifdefs to #define the relevant functions to empty macros to
placate the warnings.
I also reorganized the applets.c code to make adding such an #else case less
of a pain (and make the need for prototyping go away by moving the functions
up before they were used, and generally wind up with fewer #ifdefs in
the code by putting all the logic in one place). This resulted in a huge
seeming patch, when most if it just moves code from one place to another
without touching it...
Upside: make allyesconfig and make allnoconfig should both work now.
For certain non-gcc compilers, alloca_h is defined (included) but there,
no alloca() is declared. Fallback to malloc if _ALLOCA_H is defined but
still, there is no alloca() in the included _ALLOCA_H.
Hi!
I've created a patch to busybox' build system to allow building it in
separate tree in a manner similar to kbuild from kernel version 2.6.
That is, one runs command like
'make O=/build/some/where/for/specific/target/and/options'
and everything is built in this exact directory, provided that it exists.
I understand that applyingc such invasive changes during 'release
candidates' stage of development is at best unwise. So, i'm currently
asking for comments about this patch, starting from whether such thing
is needed at all to whether it coded properly.
'make check' should work now, and one make creates Makefile in build
directory, so one can run 'make' in build directory after that.
One possible caveat is that if we build in some directory other than
source one, the source directory should be 'distclean'ed first.
egor
