[PATCH] some Mac OS X fixes

Devin Bayer devin at freeshell.org
Thu Feb 23 03:18:31 UTC 2006


On Feb 22, 2006, at 10:34, Rob Landley wrote:
> On Wednesday 22 February 2006 11:58 am, Devin Bayer wrote:
>>
>> 1) I need to create an "#ifdef __APPLE__" guard, but it would be
>> better if I could use an "#ifndef CLEARENV_AVAILABLE" guard, which
>> would be automatically detected.  Then when porting to another C
>> library,  they wouldn't have to change as much.
>
> I have no problem with #ifdefs in platform.h and platform.c.   
> That's what
> they're for.  Any platform-specific ugliness you need, no matter  
> how ugly, is
> ok in there.

I wasn't talking about ugliness.  Let's say somebody patches uClibc  
so that it doesn't contain any GNU'isms like clearenv().  It would be  
great if busybox compiled against that library without having to  
modify platform.h/c.  The only way to do that is by auto-detecting  
individual functions instead of the whole c library at once.  We  
could autodetect if there was a conforming clearenv() with a  
configure step.

>> 2) There is a need to to automatically _configure_ features.   
>> Because...
>>    * This is because a user running "make defconfig/allyesconfig"
>>      should be left with a usable configuration.
>
> make allnoconfig and make defconfig should be a usable  
> configuration.  Make
> yesconfig is for code coverage testing: it should compile but  
> nobody said
> anything about usable. :)

OK, but how to make allyesconfig compile on OS X?  I think the best  
way is by making some configure options like CONFIG_LOSETUP not be  
selected when there is no linux/loop.h header available.  So before  
doing allyesconfig, auto-configuring has to be done.

> I've pondered adding a CONFIG_HAS_PROC and tagging various apps  
> that need PROC
> with that, so they disappear out of the menu if you switch that off.
>
> Hmmm...  Poking at the way the linux kernel configures different  
> platforms, I
> see that they start with a different top level Kconfig file...  We  
> may need a
> platform directory to hold those sooner rather than later...

That would probably work.  It sounds harder to maintain and less  
useful then keeping one unified configure system.

>> But the cleanest solution is to add automatic configuration to
>> menuconfig.  Make one subscreen an "Automatically Detected Settings"
>> screen, and fill it in when running for the first time, but allow
>> manual user overrides.  This will clear all the check_*() stuff out
>> of the Makefile also.
>
> That's another option.
>
> What kind of settings are we talking about here?  (Autodetecting  
> and bringing
> them up in a configurator sounds iffy.  If nothing else, the entire  
> menu
> should have the CONFIG_NITPICK guard hiding it, once we get around  
> to doing
> that...)

I was thinking CONFIG_BUILTIN_CLEARENV and CONFIG_LINUX.  Then:
   * CONFIG_LOSETUP would have a dependency on CONFIG_LINUX.
   * In platform.h, clearenv()'s declaration would be guarded by  
USE_BUILTIN_CLEARENV

But I suggest it not be hidden in CONFIG_NITPICK, because when  
something isn't detected the way it should be there is likely  
something wrong with the user's setup (LD_LIBRARY_PATH or the like).  
Plus, someone may have their own reasons to use an internal library  
function instead of the c-library one, even when the c-library one is  
available.

-- 
Devin Bayer



More information about the busybox mailing list