Brad, you gave the solution to your problem in this e-mail. Since you
basically have control over the build environment, just define a CFLAG
at build time that assigns HTTPD_ROOT to whatever makes sense as
a default on Netware.
As for what to do when Apache is installed to a non-standard path, just
create a small scripte (modeled after apachectl), which starts Apache with
the -d flag. This is what Covalent does, since we have to deliver a
pre-built Apache binary.
Ryan
On Thursday 13 September 2001 08:08 am, Brad Nicholes wrote:
> 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.
--
______________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
