Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 2035 invoked by uid 500); 13 Feb 2001 14:38:50 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 99284 invoked from network); 13 Feb 2001 14:33:43 -0000 Date: Tue, 13 Feb 2001 06:34:16 -0800 (PST) From: rbb@covalent.net X-Sender: rbb@koj To: "Roy T. Fielding" cc: new-httpd@apache.org, dev@apr.apache.org Subject: Re: build blues In-Reply-To: <20010212233047.B22954@waka.ebuilt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > * merged apr-conf.m4 and apr_common.m4 into build/acinclude.m4 > and name-protected all of the macro names > -- have not yet name-protected the variables within the macros Those two files had two very different uses. The first is used for APR itself, and is a bunch of macros that no application using APR should need or even have to think about. The second is a set of macros that APR provides for applications. I would like to see these kept separate, because it makes it much easier for application programmers to locate the macros they want to use. > * removed some unused macros such as? > * libtoolize --automake --copy --force > [the only way we ever want to call libtoolize] why --automake? > All of the above is done for apr and it is building fine. What I still > need to do is > > * make each "top-most" buildconf.sh set up the subdirectory configures > directly with autoheader and autoconf, rather than running each of > their buildconf.sh scripts. This will remove most of the redundant > libtool and configure checks, force the whole tree to be built with a > consistent set of flags, and allow each independent tree's buildconf.sh > to be specialized for standalone builds of that tree. Each subdir will still run stand-alone, correct? There is a part of me that dislikes this, because it sounds like it will be possible to configure Apache without running APR's buildconf script, which means that any bugs in APR's buildconf script are likely to be hidden from a lot of the APR developers. Other than those few comments, this is awesome. Ryan _______________________________________________________________________________ Ryan Bloom rbb@apache.org 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------