httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: Hard coded HTTPD_ROOT in httpd.h...
Date Thu, 13 Sep 2001 15:08:53 GMT
   Thank you for the feedback but I am still concerned about how this is going to work on NetWare.
 Here are the reasons why:

1) NetWare like Win32 and OS2, does not have a configure utility therefore config.layout will
do us no good at all.  In fact 99% of the compile time configuration is meaningless to us
mostly due to the next reason.

2) Unlike the Unix world, and I wish this were not the case for us, NetWare does not have
an open development environment.  Our tools such as Code Warrior cost money and are not widely
available.  Due to this fact we can not expect the average user to download, build and install
Apache from source.  Our users depend on prebuilt binaries that will work in all NetWare configurations.
 To my knowledge, and I hope I am wrong, there are only a hand full of developers that have
actually downloaded the source and built it for NetWare in comparison to a relatively large
number of NetWare users that have downloaded the binaries and are either playing with it or
deploying it.  BTW, Apache 1.3.20 will be shipping with NetWare 6 so this relatively large
number will grow even larger soon.

3) Bill suggested that we look at the Win32 hooks.  I'm not quite sure what you mean by that.
 Unless they are some type of Apache hook, it won't do us any good either.  NetWare does not
have a hooking mechanism that will allow us to alter something like HTTP_ROOT at run-time.
 When the Apache binary is envoked, the first thing we hit is main().  According to the code,
def_server_root is initialized to HTTPD_ROOT and unless there is a -f or -d parameter specified,
a hard coded path will be used and we will fail.

The only possible workaround that I can see at the moment is #define'ing HTTP_ROOT as getcwd()
which will at least get us in the ball park.  I would greatly appreciate any other suggestions
from those who know this code much better than I do (which could be just about anybody :)
 )

thanks,
Brad

>>> marcs@znep.com Thursday, September 13, 2001 12:49:55 AM >>>
On Wed, 12 Sep 2001, Greg Stein wrote:

> On Wed, Sep 12, 2001 at 10:34:03PM -0400, Rodent of Unusual Size wrote:
> > * On 2001-09-12 at 21:11,
> >   Ryan Bloom <rbb@covalent.net> excited the electrons to say:
> > > 
> > > This is why we have config.layout.
> > 
> > It is not just -f, it is -d as well.  I think most installations use
> > either one of these or the default location set by the layout.
> > Not a problem, I think.
> 
> If the hard-coded default is never used, then why don't we just toss it, and
> require people to pass/use a root?

It is used.  By default.  A default "configure --prefix=/under/my/hat
&& make && make install" will result in the default defines being used.

We need some way to know where to look for config files.  This can
be done at compile time or at run time.

Right now we support it being done at compile time with these defines.
Lots of people do use it.  Note that it is designed so that it 
can be easily overridden from the #defined path at compile time, and
it often is.

It can be overridden at run time with command line options.  The
original suggestion that started this thread was to base it off
the current working directory.  I just don't see that offering any 
real advantage, since command line options are directly associated 
with the execution of the program, as opposed to the working directory
which is a OS maintained bit of information.



Mime
View raw message