Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 19990 invoked by uid 6000); 7 Jan 2000 15:16:46 -0000 Received: (qmail 19983 invoked from network); 7 Jan 2000 15:16:44 -0000 Received: from goliath.siemens.de (194.138.37.131) by taz.hyperreal.org with SMTP; 7 Jan 2000 15:16:44 -0000 X-Envelope-Sender-Is: martin.kraemer@mch.sni.de (at relayer goliath.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.9.3/8.9.3) with ESMTP id QAA29599 for ; Fri, 7 Jan 2000 16:16:38 +0100 (MET) Received: from deejai.mch.sni.de (deejai.mch.sni.de [139.25.105.242]) by mail1.siemens.de (8.9.3/8.9.3) with ESMTP id QAA09548 for ; Fri, 7 Jan 2000 16:16:37 +0100 (MET) Received: (from martin@localhost) by deejai.mch.sni.de (8.8.7/8.8.7(UNIX)) id QAA07061 for new-httpd@apache.org; Fri, 7 Jan 2000 16:16:36 +0100 (MET) Date: Fri, 7 Jan 2000 16:16:34 +0100 From: Martin Kraemer To: new-httpd@apache.org Subject: Trouble with --shadow= Message-ID: <20000107161633.A6961@deejai.mch.sni.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i X-Operating-System: SINIX-D 5.41 C1001 X-Organization: Fujitsu Siemens Computers (Muenchen, W.Germany) X-Phone: +49-89-636-46021 X-Disclaimer: THE COMMENTS CONTAINED IN THIS MESSAGE REFLECT THE VIEWS OF THE WRITER AND ARE NOT NECESSARILY THE VIEWS OF SIEMENS AG X-No-Junk-Mail: I do not want to get *any* junk mail. Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org Status: O I tried the --shadow= feature and am having difficulties understanding the philosophy behind it. a) why is there a two-step shadow tree in the first place? One copy of the tree ("external" shadow) plus one platform specific copy ("internal" shadow). IMO it would have been sufficient to have only one (the "internal") copy. b) *If* there is an external shadow, then there must be a way to use it for multiple architectures. In this case, it should *NOT* have another src/ directory which leads to the incorrect assumption that files in src/ may be used for compilation (and only their object files are stored in platform specific directories). And of course, there must be a way to create a shadow tree for more than one architecture. That however DOES NOT WORK at all, because an attempt to create a shadow tree for architecture B into an existing tree for architecture A will first erase everything in the common ( ;-) shadow directory, before installing a B-only shadow tree. The only workaround I see for this is: mkdir -p /nfs/apa/shadow/A mkdir /nfs/apa/shadow/B rsh A 'cd apache_x.y.z/; ./configure --shadow=/nfs/apa/shadow/A' rsh B 'cd apache_x.y.z/; ./configure --shadow=/nfs/apa/shadow/B' mv /nfs/apa/shadow/A/* /nfs/apa/shadow/ mv /nfs/apa/shadow/B/*.B /nfs/apa/shadow/ rm -fr /nfs/apa/shadow/A /nfs/apa/shadow/B /nfs/apa/shadow/src But that's not something I would like to do manually. IMO, it's configure's job. c) config.status was intended as a way to re-configure apache with the same settings as before. There is a "config.status" generated into the external shadow; however, when you call it, it only produces errors because it immediately removes the old external shadow copy: Configuring for Apache, Version 1.3.9 + using installation path layout: Apache (config.layout) + creating external package shadow tree (/tmp/apa) ./configure: src/helpers/mkshadow.sh: nicht gefunden + switching to external package shadow tree (/tmp/apa) ./configure: src/helpers/GuessOS: nicht gefunden + creating Makefile (shadow wrapper) + creating internal platform shadow tree (src.) ./configure: src/helpers/mkshadow.sh: nicht gefunden ./configure: src./helpers/getuid.sh: nicht gefunden ./configure: src./helpers/buildinfo.sh: nicht gefunden ./configure: src./helpers/buildinfo.sh: nicht gefunden Creating Makefile. ./configure: Makefile.tmpl: kann nicht eroeffnet werden ./configure: src./apaci: kann nicht erzeugt werden Exit 1 The correct way to re-run the configuration should be described (currently, there doesn't seem to be any, as re-running "configure --shadow=..." deletes not the platform specific directory only, but *ALL* directories. d) configure should make sure that no more than the original apache files are copied into the shadow tree. If you decide to put the shadow within the apache_x.y.z/ tree, then this is not guaranteed: you will get another copy of your external and internal shadow trees into your shadow trees. :-( OTOH, mkshadow takes great pains to detect relative paths (which in most cases are used within the source tree). Martin -- | Fujitsu Siemens | 81730 Munich, Germany