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