From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26327 invoked by alias); 18 Apr 2012 16:04:56 -0000 Received: (qmail 26262 invoked by uid 22791); 18 Apr 2012 16:04:52 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 Apr 2012 16:04:34 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3IG4HMi024928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Apr 2012 12:04:17 -0400 Received: from host2.jankratochvil.net (ovpn-116-78.ams2.redhat.com [10.36.116.78]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3IG4Dbd007527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 18 Apr 2012 12:04:16 -0400 Date: Wed, 18 Apr 2012 16:09:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: Joel Brobecker , Yao Qi , gdb-patches@sourceware.org Subject: Re: Fix in-src-tree builds by making gdbserver/gnulib/ a separate library (a la libiberty, etc.), and adding ACX_CONFIGURE_DIR. Message-ID: <20120418160412.GA18303@host2.jankratochvil.net> References: <20120417232552.GS2852@adacore.com> <4F8E860F.8050906@redhat.com> <20120418092859.GA5887@host2.jankratochvil.net> <4F8E949E.1000702@redhat.com> <20120418123254.GA11744@host2.jankratochvil.net> <4F8EB632.6050501@redhat.com> <20120418125144.GA12372@host2.jankratochvil.net> <4F8EBBA6.10507@redhat.com> <20120418154041.GA17262@host2.jankratochvil.net> <4F8EE321.2010105@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F8EE321.2010105@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00592.txt.bz2 On Wed, 18 Apr 2012 17:52:01 +0200, Pedro Alves wrote: > I guess it depends on which tools you use. I just keep multiple tabs > open on my terminal, and switching is just -/. I do no switching, I just run it from a single place, I like things simple. > > And why to separate the two directories? > > * Object/binary files are filtered out of versioning system handling by > > .cvsignore/.gitignore (it does not work with GDB, I guess I should fix it). > > To start from scratch, from "rm -rf build". No cruft left in the source tree, > not that which I don't want anyway. "make distclean" doesn't clean up everything, > and which git could cleanup _everything_ out (I think), I frequently have > non-checked-in files in the src tree that I don't want to wipe. I do 'git clean -dfx', I understand your "non-checked-in files" part, OK... > > > * Why to have multiple builds out of a single src tree? I do not remember > > I would ever use that case. And if I had to I just copy the sources. > > And if I need to save space of the sources files, negligible to the object > > files size anyway, either > > * filesystem automatic deduplication does it for me automatically anyway. > > * or I can just use hardlinks for the source files (cp -al). > > Oh, that's something that I do all the time. E.g., one regular build, one > --enable-targets=all build, one -O2 build. Separate directories means > I don't have to remember to reconfigure the tree. I just type "make", > and if necessary, that triggers a reconfiguration. This leads to the bugs one forgets to add a file to the repository and one thinks it still works. This is exactly why I always run the tests completely from scratch, from a new checkout from the repository. Machines nowadays just have no performance and disk space problems with it. > > Then there is the toplevel gnulib directory. [...] > But in order to get there, we'd still want (IMO), this gnulib wrapper, so I see > this is a necessary first step. I thought parent of gnulib would be the toplevel configure, without any wrapper? I sure may miss many things. Thanks, Jan