httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rasmus Lerdorf <>
Subject Re: Building and Linking 3rd Party Modules within Apache 2.0 Source
Date Thu, 19 Oct 2000 01:32:51 GMT
> > > On Wed, 18 Oct 2000, Rasmus Lerdorf wrote:
> > > 
> > > > No, we are just telling them to install autoconf, that's all.  
> > > 
> > > And the modules need to understand how to hook into our config system, but
> > > that's relatively minor.
> > 
> > They need to provide a config.m4 and a file, sure.  Beyond
> > providing those, they don't really do the hooking.  It's the Apache build
> > system that does the pulling.
> Yeah, that's what I meant, and the config.m4 file is easy to create, but
> they will need to do it.  Like I said, minor but something to
> remember.  :-)

In PHP we have an 'ext_skel' script which generates a skeleton PHP
extension which has all simple versions of these various required
files.  It even generates a simple C file that has all the right
components.  I have a series of slides on how to add an extension to PHP
which shows how this works:

Go to slide 21 and read from there.

To summarize, all it involves is:

cd ext
./ext_skel --extname=foo
(tweak config.m4 to add correct --with-foo switch and dependancy checking)
cd ..
./configure --with-foo

Now, once buildconf has been run once on it, the ext/foo directory can be
tarred up and distributed and it will compile as a standalone extension.  
So the above steps is what an extension author (module author in Apache
speak) would do and then he would distribute that tarball and a user would
be able to build it standalone as a DSO.  To build it into Apache as a
static module, currently the user would have to copy it into his source
tree (just like with the current 1.3 mechanism) and run the top-level
./buildconf script which requires autoconf/automake/libtool.  

It should be possible to build some gear that removes that
autoconf/automake/libtool requirement for a static module.  It would look
similar to the 1.3 approach where the module would need to identify which
other libs it needs to have linked in and we would need some sort of
configure flag that tells the configure system to go look for this
information and include the module.  I think much of the 1.3 stuff to do
this could be re-used for this case.


View raw message