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
>>> [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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.
