Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-Id: <sba077ac.022@prv-mail20.provo.novell.com>
Date: Thu, 13 Sep 2001 09:08:53 -0600
From: "Brad Nicholes" <BNICHOLES@novell.com>
To: <dev@httpd.apache.org>,<marcs@znep.com>
Subject: Re: Hard coded HTTPD_ROOT in httpd.h...
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

   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:
> > >=20
> > > This is why we have config.layout.
> >=20
> > 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.
>=20
> 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=3D/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=20
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=20
real advantage, since command line options are directly associated=20
with the execution of the program, as opposed to the working directory
which is a OS maintained bit of information.