[PATCH] remove "ENABLE_" symbols from httpd.c

[Rob Landley]

On Tuesday 11 April 2006 10:00 am, Bernhard Fischer wrote:
> On Tue, Apr 11, 2006 at 09:50:35AM -0400, Robert P. J. Day wrote:
> >On Tue, 11 Apr 2006, Bernhard Fischer wrote:
> >> The defined ENABLE macros there are for the STANDALONE version of
> >> http. We currently don't care about the standalone stuff, but i see
> >> no reason to rip the standalone stuff out as we will need to put it
> >> back in anyway.
> >
> >... big snip ...
> >
> >ok, i'll go over that later today.  thanks.
> >
> >rday
> >
> >p.s.  speaking of STANDALONE, i'm assuming one of the goals is to add
> >the STANDALONE option to the config menu, yes?
>
> I thought that this was a sensible thing to do, but landley objected.

I objected to the way you did it.

I see standalone as a single switch you hit that builds everything standalone.  
I don't want to use the module thing to build some things standalone and some 
things monolithic, because that's just silly.

If somebody wants to build two different monolithic executables (a very common 
use case is building the stuff requiring the suid bit -- I.E. the old 
tinylogin stuff -- as one executable, and all the stuff that doesn't need the 
suid bit as a second executable), the "modular" stuff doesn't handle that.  
If you want some standalone applets statically linked (for initramfs, 
perhaps) and others dynamically linked, it doesn't handle that either.

In general, I want to keep the configuration _simple_.  Right now there are 
cases where you have to have three configs and build three times to get the 
level of control you want, and I don't want a halfway solution that lets you 
build different types of things at once in certain circumstances, but not 
all.

By the way, you can build standalone right now.  Just select one app, build 
it, mv busybox appname, select the next, build that...  The downside is it 
has about 4k of overhead code (the multiplexer stuff) in each applet, and 
it's a serious pain.

> He and (according to him) his fellows at timesys

They really don't have much say in this, I just bounce ideas off of 'em 
because they actually deploy this stuff and support customers using it, and 
because they're handy.  I make my own decisions, thanks. :)

> don't see a reason why 
> the standalone stuff should be selectable in the config.

It should be selectable.  The same way static is selectable.  We don't have 
"statically link against libm but keep libc dynamic".  We have one big switch 
that says "link against libraries statically" or "link against libraries 
dynamically".

> You should be able to find a proposed patch which did expose the
> standalone stuff in (menu)config in the archives from last month or so,
> if you're curious.

Using modular to select it is what I objected to.  Yes, our menuconfig 
inherited that facility from the kernel.  No, I don't think using it for this 
is a good idea.

Rob
-- 
Never bet against the cheap plastic solution.