[PATCH] some Mac OS X fixes

[Rob Landley]

On Wednesday 22 February 2006 11:58 am, Devin Bayer wrote:
> On Feb 22, 2006, at 7:50, Rob Landley wrote:
> > On Wednesday 22 February 2006 2:18 am, Devin Bayer wrote:
> >> On Feb 21, 2006, at 2:37, Vladimir N. Oleynik wrote:
> >>> But, have Mac OS X specified variable for Makefile?
> >>> I think, best if added this as .ifdef for libbb/Makefile.in
> >
> > As far as the C code goes, this sort of thing is why we added
> > platform.h and
> > platform.c.  I'd like to minimize platform-specific stuff in the
> > applets
> > themselves.  If clearenv() has to be a function that everybody
> > calls but it's
> > a NOP on platforms other than macosx, and the details of that are in
> > platform.h and/or platform.c, I can live with that...
> >
> > As far as the makefiles go, what specific behavior is needed?
> > (I've cherry
> > picked some stuff out of the big patch already, but lots of the
> > rest I just
> > skipped over to look at later...)
>
> Keeping clearenv() in platform.c is no problem for me.  FYI, it's not
> an NOP on linux - it's a glibc'ism.  A few points:
>
> 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.

If you could keep the Apple stuff together, though, that would be nice.  (At 
some point if it gets big enough platform.* may get split into a platform 
subdirectory with linux.* and mac.* in it.  But that's still an if.)

> 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. :)

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...

>    * The check_strip() and check_ld() calls in the Makefile are
> basically
>      just short configure scripts.
>
> So, I would say the easiest solution is keep adding more check_*()
> scripts in the Makefile, and have them run and set CFLAGS and
> environmental variables to effect the C code and menuconfig's behavior.

Possibly splitting them out into some kind of check.mk similar to rules.mk?

> 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...)

Rob
-- 
Never bet against the cheap plastic solution.