[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