httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "R, Rajesh (STSD)" <>
Subject Problem in "autoconf" installation
Date Thu, 21 Jul 2005 11:24:38 GMT


I am trying to install a module for Apache2 in Tru64. 
While trying to install "autoconf" , I received the following 
Error .,

-----------checking for a BSD-compatible install... config/install-sh -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking for expr... /sbin/expr
checking for gm4... no
checking for gnum4... no
checking for m4... /usr/bin/m4
checking whether m4 supports frozen files... no
configure: error: GNU M4 1.4 is required

Even after installing GNU M4 1.4 , I get the same error ...
Please help me out.

Thanks in advance.

--Rajesh R

-----Original Message-----
From: Sander Temme [] 
Sent: Thursday, July 21, 2005 3:44 PM
Subject: ApacheCon BOF about Module Repository

Hash: SHA1

All who are at ApacheCon or are otherwise interested,

I snatched a BOF slot tonight (Thursday the 21st) at 20:30 to discuss
ideas for dealing with modules inside and outside the httpd

This is so far just an idea... I named it TCAHMAN (pronounced
"Tikkaman") for The Comprehensive Apache Httpd Module Archive Network.

The basic premise is to run:

$ ./configure (...) --with-tcahman-shared=funkymod (...)

and configure will contact the tcahman server (a.k.a., download the source code for funkymod and compile
it into the server as an so. Or, it could access a locally downloaded
module tarball in case the build box can't see the net:

$ ./configure (...) --with-tcahman=/path/to/funkymod.tar.gz

will find the tarball in the file system and compile it (statically, in
this case) into the server. In a similar fashion, an installed httpd
could come with a script that can download, build and install a module
on the existing server. Perhaps an enhancement to APXS? For

$ apxs build --with-tcahman=funkymod

On the server side of TCAHMAN, the main issue is Organization. I would
like to model this after CPAN, but I have no idea how CPAN works.... in
any case, what we'd need is a standard for what module code and its
meta-data looks like: proper autoconf language to get it built, name and
description for the search engine, which Apache
version(s) the tarball works with, etc. The other side of the
organization aspect is who gets to upload modules to this archive. Do we
just open it up? Or do we impose any regulations on code quality or
evilness? Who gets to enforce this (major time sink danger here)?  
What language would we use to make sure people don't attribute uploads
of third-party code to us? Will have a feedback
engine where users can tell module developers their shit is broken?

This or a similar construction would provide people who build httpd
easier access to third-party modules. It would also provide a way out
for modules we might not want in the core distribution anymore, but
would still like to make available. It gives module authors visibility
to users, to get their code in front of people who might want to run it.

Let's bat this around tonight and see if this is something we want to
do, and how we would go about it. Is there any beer left over from the


- --    
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF

Version: GnuPG v1.4.1 (Darwin)


View raw message