Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 66561 invoked by uid 500); 13 Sep 2002 17:36:28 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 66550 invoked from network); 13 Sep 2002 17:36:28 -0000 X-Authentication-Warning: cancer.clove.org: jerenk set sender to jerenkrantz@apache.org using -f Date: Fri, 13 Sep 2002 10:36:31 -0700 From: Justin Erenkrantz To: dev@apr.apache.org Subject: [PROPOSAL] Create apr-build repository Message-ID: <20020913173631.GT1555@apache.org> Mail-Followup-To: Justin Erenkrantz , dev@apr.apache.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Since we have a lot of files within APR that we want to share across other projects to help support the build system, I think we should create an apr-build repository that contains these files so that other projects can check out these projects and have one unified version of these files rather than copying them over from APR and potentially getting them out-of-sync. Namely the files we would start with would be: apr-build/ autoconf/ PrintPath apr_common.m4 config.guess config.sub find_apr.m4 (ambivalent about being in here, but perhaps) get-version.sh install.sh rules.mk.in (perhaps, but I'm not sure) aplibtool/ aplibtool.c This may also provide a proper resting place for my jlibtool.c (which as Fred points out needs autoconf scripts of its own to properly detect the OS). I think we could rely on CVS modules to autocheckout the files, but I'm not exactly clear how that would work. Thoughts? -- justin