SVN checkin 11462 is broken.
Rob Landley
rob at landley.net
Fri Sep 16 15:43:49 UTC 2005
On Friday 16 September 2005 03:11, Vladimir N. Oleynik wrote:
> Rob,
>
> > The ENABLE_* macros are always defined. They may be 0 or 1, but they are
> > always defined as _something_. Therefore, code like this is a NOP:
>
> May be.
>
> I already asked about this problem.
> Why config.h file it is split into 2 parts (+bb_config.h)
> why it is used different namespaces (CONFIG_*, ENABLE_*, BB_*)?
And I already answered you, several times. Here's the most recent, which you
never replied to asking for any more clarification:
http://www.busybox.net/lists/busybox/2005-September/016053.html
This code originally went in as svn commits 10929 and 10944 back in July.
There was a big, big, big long discussion of it starting here:
http://www.busybox.net/lists/busybox/2005-July/015075.html
Erik Andersen suggested using the preprocessor:
http://www.busybox.net/lists/busybox/2005-July/015079.html
The original patch that got applied came from Shaun Jackman:
http://www.busybox.net/lists/busybox/2005-July/015120.html
And Erik helped debug it:
http://www.busybox.net/lists/busybox/2005-July/015160.html
And the bug (bloat) Erik pointed out in our original implementaiton required
us to switch to a different symbol:
http://www.busybox.net/lists/busybox/2005-July/015163.html
All the discussion for this was public. It took place on this list, at great
length. All these issues were gone over months ago. Really.
> Where the documentation that this all to understand?
> For example: the kernel (bigger project) use only
> CONFIG_* and one config.h file!
The Linux kernel is where I learned this stuff. Didn't you read Greg
Kroah-hartman's "documentation/coding-style and beyond" from his 2002 OLS
presentation?
http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_paper/codingstyle.ps
Excerpt:
---------------------------
3.7 No ifdef in .c code
With the wide number of different processors, dif- ferent configuration
options, and variations of the same base hardware types that Linux runs on,
it is very easy to start having a lot of ifdef statements in your code. This
is not the proper thing to do. Instead, place the ifdef in a header file, and
pro- vide empty inline functions if the code is not to be included.
As an example, consider the code in drivers/usb/hid-core.c as shown in Figure
4.
Here the author does not want to call hiddev hid event() if a specific
configuration option is not enabled. This is because that function is not
present if the configuration option is not enabled.
To remove this ifdef, the changes shown in Figure 5 were made.
-------------------------
> What is shit:
> $(ARCHIVAL_DIR)$(ARCHIVAL_AR): $(patsubst %,$(ARCHIVAL_DIR)%,
> $(ARCHIVAL-y)) ?
> Why not
> $(ARCHIVAL_AR): $(ARCHIVAL-y)
> ?
Ask vapier. He's the one who checked in svn 10923, 7 weeks ago. I've
mentioned previously that my make-fu is weak.
Rob
More information about the busybox
mailing list