PLATFORM_LINUX is evil

[Denys Vlasenko]

On Wednesday 23 February 2011 06:16, Rob Landley wrote:
> So if you start with "allnoconfig" and look to see what applets you can
> enable, things like "mount" don't exist for you unless you know to look
> for them.  This adds a new layer of black magic and a-priori knowledge
> required in order to build busybox.  That's not a good thing.

Istead of "depends on PLATFORM_LINUX", we can use "select PLATFORM_LINUX".

Then BSD people will come complaining that they can't easily select
a config without inadvertently turning on linux-specific bits...


> Busybox has always been a Linux program.  Pretending it's not at least
> _primarily_ a Linux program is silly.  Anything that makes it harder to
> use on Linux is _immensely_ counterproductive.  If you're trying to use
> it on anything other than Linux, we have to assume you're an expert and
> when it breaks you get to keep the pieces.
> 
> If you really felt the need to have such a symbol, it would have made
> more sense for it to have no effect when off and remove things when it
> was switched on, so it didn't break allnoconfig.

I tend to avoid "negative" config symbols (and any kind of variables
in general), because resultant constructs of the "if not not_foo ...."
form are hard to read.


> We've got plenty of 
> symbols such as CONFIG_SELINUX that render busybox unbuildable by normal
> humans when enabled, which is why "allyesconfig" is useless

You are right. Allnoconfig, allyesconfig and randconfig are useless
(in some sense of the word), they need to be sanitized prior to use.
See scripts/randomtest for an example.


> and
> defconfig needs special handling as a maximal sane configuration.  But I
> personally don't see why you'd ever treat busybox on non-linux as
> anything _other_ than something for experts.  (It's not like writing
> toybox or Android's toolbox was all that _hard_.  If the macintosh
> really needs its own busybox equvialent they can darn well write one.)

What do you propose to do?

-- 
vda