Problem in "autoconf" installation

["R, Rajesh (STSD)" <ra...@hp.com>]

Hello,

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 [mailto:sander@temme.net] 
Sent: Thursday, July 21, 2005 3:44 PM
To: dev@httpd.apache.org
Subject: ApacheCon BOF about Module Repository

-----BEGIN PGP SIGNED MESSAGE-----
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
distribution.

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.  
modules.apache.org), 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
instance:

$ 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 modules.apache.org 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
Hackathon?

S.

- --
sander@temme.net              http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFC33WCnjkrwtLH+RIRAl2eAJwITvvpbf297JUUVg2e1kPsWPiLpQCfTbCU
2y4cd6SZ+Rj83JO2IEY2y2E=
=RwhU
-----END PGP SIGNATURE-----