httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: Hard coded HTTPD_ROOT in httpd.h...
Date Thu, 13 Sep 2001 15:53:14 GMT

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.


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
> >>> 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 <> 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
Covalent Technologies

View raw message