From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14333 invoked by alias); 18 Apr 2012 15:52:40 -0000 Received: (qmail 14195 invoked by uid 22791); 18 Apr 2012 15:52:38 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,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 15:52:20 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3IFq3OX001619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Apr 2012 11:52:03 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q3IFq1Eb027244; Wed, 18 Apr 2012 11:52:02 -0400 Message-ID: <4F8EE321.2010105@redhat.com> Date: Wed, 18 Apr 2012 16:04:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jan Kratochvil 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. References: <20120417170521.GA9906@host2.jankratochvil.net> <4F8DA538.1060000@redhat.com> <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> In-Reply-To: <20120418154041.GA17262@host2.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00590.txt.bz2 On 04/18/2012 04:40 PM, Jan Kratochvil wrote: > On Wed, 18 Apr 2012 15:03:34 +0200, Pedro Alves wrote: >> On 04/18/2012 01:51 PM, Jan Kratochvil wrote: >> >>> On Wed, 18 Apr 2012 14:40:18 +0200, Pedro Alves wrote: >>>>> This is no different from src/gdb/ vs build/gdb. >>> I (and I guess most of the users) always use just in-src-tree-build with src/ >>> and no separate build/ . >> >> Eh. Why would you prefer doing things that way? > > This is offtopic but: > > After 6 years I still have not figured out a single reason why to do > out-of-src-tree build. It is difficult to switch directories back and forth > between editing .c files and running make. I guess it depends on which tools you use. I just keep multiple tabs open on my terminal, and switching is just -/. > > 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. > * 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. I have one gdbserver build directory for each of the sh, mips, arm, ppc, etc. cross compilers, since I'm touching all those ports in the multi-process+multi-arch series. > > I probably miss some use case but I never met such use case in the 6 years > heavily involved with the toolchain (and neither in its lighter use before). > > >>> From my point of view it does not matter how it >>> looks in the out-of-src-tree build. I understand you have to introduce >>> separate build directory for gnulib/ in your layout. >>> >>> Couldn't you just use >>> gdb/configure.ac: ACX_CONFIGURE_DIR(["gnulib-src"], ["build-gnulib-gdb"]) >>> gdb/gdbserver/configure.ac: ACX_CONFIGURE_DIR(["../gnulib-src"], ["build-gnulib-gdbserver"]) >>> and having during in-src-tree build: >>> src/gdb/gnulib-src/gnulib/ >>> src/gdb/build-gnulib-gdb/gnulib/ >>> src/gdb/gdbserver/build-gnulib-gdbserver/gnulib/ >> >> I could, but look at those duplicate "gnulib/"s anyway... > > It is all about subjective orientation, I find it easier that at least the > parent directory name is unique. Okay, I'll do that. > This double-directory layout and out-of-src-tree part even during in-src-tree > part is sure not ideal. Do you have objections to this layout of slightly > less ambigous names? I do not mind renaming it any way, just to keep it > unique as I propose above. I don't. >> I really don't think we should complicate the build to somehow change that. > > Then there is the toplevel gnulib directory. I know, I was the one to propose it. :-) That's involve a lot of work: top level work; gdb's configure that descends into gdbserver would need to be touched; adapting to the gdb/common/ dir not being anymore in the same relative path; probably other hidden dragons. But in order to get there, we'd still want (IMO), this gnulib wrapper, so I see this is a necessary first step. -- Pedro Alves