You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2000/12/05 16:04:26 UTC
building experimental modules with httpd-2.0 tree
If I recreate modules/extra and populate it with the old Makefile.in
and config.m4 (and .cvsignore for good measure), --with-module= works
again.
Unless another scheme has been devised for httpd-2.0, I (or somebody
who likes moving around ,v files) will recreate the directory ("cvs add
extra") and copy in the three ,v files from apache-2.0.
Thanks,
Jeff
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: building experimental modules with httpd-2.0 tree
Posted by Jeff Trawick <tr...@bellsouth.net>.
Greg Stein <gs...@lyra.org> writes:
> How about if:
>
> 1) we create modules/third-party/
nice name
> 2) provide a tool to copy over the files and insert a line(s) into config.m4
>
> If this tool is apxs, then fine, but I think a separate tool would make a
> bit more sense. So you'd have apxs for external/dynload builds, and ??? for
> within-Apache/static builds.
>
> This also clears up the configure processing: using that to do the *copy* is
> strange. It is also non-indempotent. e.g. if you run config.nice again, then
> it makes another copy. I've lost changes because of that :-(
so just edit the right file :)
>
> So, the process for a installing a third-party module into a static build:
>
> [httpd-2.0]$ support/apcopymod /home/gstein/3pmod-0.1
> (some text, saying "copying to modules/third-party)
> [httpd-2.0]$ ./configure
> ...
> [httpd-2.0]$ make
>
> A switch appears in the configure process to disable the module (apcopymod
> puts a default=yes module into config.m4).
>
> apcopymod could also look at the provided argument: a directory would copy
> over <multiple files and stuff>, and a .c file would be just a simple module
> copy. Other stuff in a directory would be:
>
> *) multiple files
> *) custom configuration stuff (.m4 files)
> *) header files
>
> This feels about right to me. Thoughts?
It sounds good to me.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: building experimental modules with httpd-2.0 tree
Posted by rb...@covalent.net.
> How about if:
>
> 1) we create modules/third-party/
> 2) provide a tool to copy over the files and insert a line(s) into config.m4
>
> If this tool is apxs, then fine, but I think a separate tool would make a
> bit more sense. So you'd have apxs for external/dynload builds, and ??? for
> within-Apache/static builds.
>
> This also clears up the configure processing: using that to do the *copy* is
> strange. It is also non-indempotent. e.g. if you run config.nice again, then
> it makes another copy. I've lost changes because of that :-(
>
> So, the process for a installing a third-party module into a static build:
>
> [httpd-2.0]$ support/apcopymod /home/gstein/3pmod-0.1
> (some text, saying "copying to modules/third-party)
> [httpd-2.0]$ ./configure
> ...
> [httpd-2.0]$ make
>
> A switch appears in the configure process to disable the module (apcopymod
> puts a default=yes module into config.m4).
>
> apcopymod could also look at the provided argument: a directory would copy
> over <multiple files and stuff>, and a .c file would be just a simple module
> copy. Other stuff in a directory would be:
>
> *) multiple files
> *) custom configuration stuff (.m4 files)
> *) header files
>
> This feels about right to me. Thoughts?
++1.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: building experimental modules with httpd-2.0 tree
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 08, 2000 at 08:43:08PM -0500, Jeff Trawick wrote:
> rbb@covalent.net writes:
>
> > > I'm with Roy... copying the files into the "extra" directory is a bit wonky.
> > > As somebody who built an external module :-), I never liked it.
> > > Specifically, mod_dav 1.0 copies itself into apache-1.3/src/modules/dav/
> > >
> > > I'd like to avoid the extra directory. If possible. (dunno if that is so)
> >
> > But dav is a big module, and really needs it's own directory
> > structure. For simple modules, it is much easier to have a single
> > directory to put them all in. Consider my mod_hf, which adds a header and
> > a footer to every page Apache sends, if this created it's own directory
> > for a two hundred line file, it would be ridiculous. Add to that what
> > happens when an admin wants to addfive or six small external modules? Do
> > we litter the modules directory? I think extra (or maybe call it
> > external) provides a nice compromise to the problems.
>
> I agree that copying to modules/extra is more than a little wonky, but
> overall I agree with Ryan. I think the extra directory (call it what
> you want) is key to the simple build support we provide for
> single-file modules. We wouldn't want to generate files in the source
> directory (e.g., /home/goober/my_downloads) so we need some place to
> put it that doesn't clobber directories where our own code lives.
How about if:
1) we create modules/third-party/
2) provide a tool to copy over the files and insert a line(s) into config.m4
If this tool is apxs, then fine, but I think a separate tool would make a
bit more sense. So you'd have apxs for external/dynload builds, and ??? for
within-Apache/static builds.
This also clears up the configure processing: using that to do the *copy* is
strange. It is also non-indempotent. e.g. if you run config.nice again, then
it makes another copy. I've lost changes because of that :-(
So, the process for a installing a third-party module into a static build:
[httpd-2.0]$ support/apcopymod /home/gstein/3pmod-0.1
(some text, saying "copying to modules/third-party)
[httpd-2.0]$ ./configure
...
[httpd-2.0]$ make
A switch appears in the configure process to disable the module (apcopymod
puts a default=yes module into config.m4).
apcopymod could also look at the provided argument: a directory would copy
over <multiple files and stuff>, and a .c file would be just a simple module
copy. Other stuff in a directory would be:
*) multiple files
*) custom configuration stuff (.m4 files)
*) header files
This feels about right to me. Thoughts?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: building experimental modules with httpd-2.0 tree
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> > I'm with Roy... copying the files into the "extra" directory is a bit wonky.
> > As somebody who built an external module :-), I never liked it.
> > Specifically, mod_dav 1.0 copies itself into apache-1.3/src/modules/dav/
> >
> > I'd like to avoid the extra directory. If possible. (dunno if that is so)
>
> But dav is a big module, and really needs it's own directory
> structure. For simple modules, it is much easier to have a single
> directory to put them all in. Consider my mod_hf, which adds a header and
> a footer to every page Apache sends, if this created it's own directory
> for a two hundred line file, it would be ridiculous. Add to that what
> happens when an admin wants to addfive or six small external modules? Do
> we litter the modules directory? I think extra (or maybe call it
> external) provides a nice compromise to the problems.
I agree that copying to modules/extra is more than a little wonky, but
overall I agree with Ryan. I think the extra directory (call it what
you want) is key to the simple build support we provide for
single-file modules. We wouldn't want to generate files in the source
directory (e.g., /home/goober/my_downloads) so we need some place to
put it that doesn't clobber directories where our own code lives.
(I just survived 24 hours with no DSL (no phone either but I don't
have much use for it).)
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: building experimental modules with httpd-2.0 tree
Posted by rb...@covalent.net.
> > > > Unless another scheme has been devised for httpd-2.0, I (or somebody
> > > > who likes moving around ,v files) will recreate the directory ("cvs add
> > > > extra") and copy in the three ,v files from apache-2.0.
> > >
> > > Why can't we change --with-module to indicate the path below
> > > modules, rather than assuming it is some bogus "extra" directory?
> >
> > I don't know what you mean... The "extra" directory has nothing to do
> > with the argument of "--with-module" (where the source code of the
> > non-standard module is stored). The "extra" directory is where we
> > copy the module for build purposes.
> >
> > Do you wish to stop copying non-standard modules to a common directory
> > ("extra") for build purposes?
>
> I'm with Roy... copying the files into the "extra" directory is a bit wonky.
> As somebody who built an external module :-), I never liked it.
> Specifically, mod_dav 1.0 copies itself into apache-1.3/src/modules/dav/
>
> I'd like to avoid the extra directory. If possible. (dunno if that is so)
But dav is a big module, and really needs it's own directory
structure. For simple modules, it is much easier to have a single
directory to put them all in. Consider my mod_hf, which adds a header and
a footer to every page Apache sends, if this created it's own directory
for a two hundred line file, it would be ridiculous. Add to that what
happens when an admin wants to addfive or six small external modules? Do
we litter the modules directory? I think extra (or maybe call it
external) provides a nice compromise to the problems.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: building experimental modules with httpd-2.0 tree
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Dec 05, 2000 at 02:46:11PM -0500, Jeff Trawick wrote:
> "Roy T. Fielding" <fi...@ebuilt.com> writes:
>
> > On Tue, Dec 05, 2000 at 10:04:26AM -0500, Jeff Trawick wrote:
> > > If I recreate modules/extra and populate it with the old Makefile.in
> > > and config.m4 (and .cvsignore for good measure), --with-module= works
> > > again.
> > >
> > > Unless another scheme has been devised for httpd-2.0, I (or somebody
> > > who likes moving around ,v files) will recreate the directory ("cvs add
> > > extra") and copy in the three ,v files from apache-2.0.
> >
> > Why can't we change --with-module to indicate the path below
> > modules, rather than assuming it is some bogus "extra" directory?
>
> I don't know what you mean... The "extra" directory has nothing to do
> with the argument of "--with-module" (where the source code of the
> non-standard module is stored). The "extra" directory is where we
> copy the module for build purposes.
>
> Do you wish to stop copying non-standard modules to a common directory
> ("extra") for build purposes?
I'm with Roy... copying the files into the "extra" directory is a bit wonky.
As somebody who built an external module :-), I never liked it.
Specifically, mod_dav 1.0 copies itself into apache-1.3/src/modules/dav/
I'd like to avoid the extra directory. If possible. (dunno if that is so)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: building experimental modules with httpd-2.0 tree
Posted by Jeff Trawick <tr...@bellsouth.net>.
"Roy T. Fielding" <fi...@ebuilt.com> writes:
> On Tue, Dec 05, 2000 at 10:04:26AM -0500, Jeff Trawick wrote:
> > If I recreate modules/extra and populate it with the old Makefile.in
> > and config.m4 (and .cvsignore for good measure), --with-module= works
> > again.
> >
> > Unless another scheme has been devised for httpd-2.0, I (or somebody
> > who likes moving around ,v files) will recreate the directory ("cvs add
> > extra") and copy in the three ,v files from apache-2.0.
>
> Why can't we change --with-module to indicate the path below
> modules, rather than assuming it is some bogus "extra" directory?
I don't know what you mean... The "extra" directory has nothing to do
with the argument of "--with-module" (where the source code of the
non-standard module is stored). The "extra" directory is where we
copy the module for build purposes.
Do you wish to stop copying non-standard modules to a common directory
("extra") for build purposes?
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: building experimental modules with httpd-2.0 tree
Posted by rb...@covalent.net.
> Why can't we change --with-module to indicate the path below
> modules, rather than assuming it is some bogus "extra" directory?
> Most third-party modules should have their own directory. Others
> should be placed according to their function.
>
> --with-module=loggers/mod_chicken_log
>
> The modules/experimental still exists.
But --with-module needs to specify where the actual module
lives. --enable-module just finds the correct module files to
enable/disable. --with-module is meant to take an external module, copy
it into the build tree, and get it building.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: building experimental modules with httpd-2.0 tree
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Tue, Dec 05, 2000 at 10:04:26AM -0500, Jeff Trawick wrote:
> If I recreate modules/extra and populate it with the old Makefile.in
> and config.m4 (and .cvsignore for good measure), --with-module= works
> again.
>
> Unless another scheme has been devised for httpd-2.0, I (or somebody
> who likes moving around ,v files) will recreate the directory ("cvs add
> extra") and copy in the three ,v files from apache-2.0.
Why can't we change --with-module to indicate the path below
modules, rather than assuming it is some bogus "extra" directory?
Most third-party modules should have their own directory. Others
should be placed according to their function.
--with-module=loggers/mod_chicken_log
The modules/experimental still exists.
....Roy