From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5FAE6C433E1 for ; Fri, 21 Aug 2020 10:15:51 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 28D7D20732 for ; Fri, 21 Aug 2020 10:15:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="h6RlaScy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 28D7D20732 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:38804 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k945O-0000OI-DX for qemu-devel@archiver.kernel.org; Fri, 21 Aug 2020 06:15:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57520) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k944E-00074E-1G for qemu-devel@nongnu.org; Fri, 21 Aug 2020 06:14:38 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:60863 helo=us-smtp-delivery-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1k944C-0000Qe-1G for qemu-devel@nongnu.org; Fri, 21 Aug 2020 06:14:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1598004875; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+eGlWmMhlbmanAEpUpUVV4Yymq2nECqPTA8XAE3mm5I=; b=h6RlaScytWvDMbjqaMhojcbKDHcqmYPMux6VzgZsMg5y179ISLvtSaznKqzK7neRC8S4nm fB+81gohxmufKPNvJVCH+mNfRtZBqtQcR0t1LSBKcX3Xwd5WNoMMCeC7jGt2FWtIsquwh4 R5kzimkIPsGg2lD3628A/ETuGO/Avz8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-377-FGiBtiDHPgOSr4P7LDUskw-1; Fri, 21 Aug 2020 06:14:26 -0400 X-MC-Unique: FGiBtiDHPgOSr4P7LDUskw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2B8BC393B4; Fri, 21 Aug 2020 10:14:25 +0000 (UTC) Received: from redhat.com (unknown [10.36.110.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 803E7795AE; Fri, 21 Aug 2020 10:14:20 +0000 (UTC) Date: Fri, 21 Aug 2020 11:14:17 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Kevin Wolf Subject: Re: [PATCH] configure: add support for psuedo-"in source tree" builds Message-ID: <20200821101417.GG251583@redhat.com> References: <20200820165543.215372-1-berrange@redhat.com> <938bfa57-01f9-a50a-6439-0965c91dce1b@redhat.com> <20200821095821.GA5153@linux.fritz.box> MIME-Version: 1.0 In-Reply-To: <20200821095821.GA5153@linux.fritz.box> User-Agent: Mutt/1.14.5 (2020-06-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0.001 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Disposition: inline Received-SPF: pass client-ip=207.211.31.81; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-1.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/21 05:15:56 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -40 X-Spam_score: -4.1 X-Spam_bar: ---- X-Spam_report: (-4.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: Stefan Hajnoczi , Peter Maydell , qemu-devel@nongnu.org, Paolo Bonzini Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Fri, Aug 21, 2020 at 11:58:21AM +0200, Kevin Wolf wrote: > Am 20.08.2020 um 19:42 hat Eric Blake geschrieben: > > On 8/20/20 11:55 AM, Daniel P. Berrangé wrote: > > > Meson requires the build dir to be separate from the source tree. Many > > > people are used to just running "./configure && make" though and the > > > meson conversion breaks that. > > > > > > This introduces some backcompat support to make it appear as if an > > > "in source tree" build is being done, but with the the results in the > > > "build/" directory. This allows "./configure && make" to work as it > > > did historically, albeit with the output binaries staying under build/. > > > > > > Signed-off-by: Daniel P. Berrangé > > > --- > > > > In addition to reviews you already have, > > > > > > > I've not tested it beyond that. Note it blows away the "build/" > > > dir each time ./configure is run so it is pristine each time. > > > > I definitely like the idea of only blowing away what we created - but if we > > created build, then recreating it for each new configure run is nice. > > I think I actually wouldn't automatically remove anything on configure. > It can be surprising behaviour for configure to delete directories, and > the old setup didn't do an automatic "make clean" either. By having a > separate build directory, manually emptying as needed has already become > easier. The issue is that previously you could do ./configure make ./configure make This isn't possible with the new system because meson will refuse to use the "build/" directory if it already contains a previous configured build. Doing "rm -rf build" in configure lets the above sequence work. I can remove the "rm -rf biuld" in configure if we are happy to require ./configure make make distclean ./configure make because the "GNUmakefile" wires up "distclean" to purge the build/ directory. > > > We could optionally symlink binaries from build/ into $PWD > > > if poeople think that is important, eg by changing GNUmakefile > > > to have: > > > > > > recurse: all > > > for bin in `find build -maxdepth 1 -type f -executable | grep -v -E '(ninjatool|config.status)'`; \ > > > > Using -maxdepth gets rid of the need to pre-create empty directories for > > nested binaries, but also loses out on binaries such as > > x86_64-softmmu/qemu-system-x86_64. Oh, it looks like meson creates > > qemu-system-x86_64 as a binary in the top level, then a symlink in its old > > location. Populating symlinks to ALL old locations is thus trickier than > > what you are proposing here, so it is fine to save that for a followup patch > > (let's get the bare minimum in first, so that at least ./configure && make > > works, before we worry about back-compat symlinks). > > Having the system emulator symlinks in the top level would be a change, > but even more convenient than the original places. I'd vote for adding > the auto-symlinking at least for the tools; if the top-level symlinks > for system emulators get also symlinked by this, that's fine, too. > > I was actually surprised that Dan reports "make check" from the source > tree to be working without the symlinks. Some code must be cleverer than > I thought! That's because "make check" is not actually running from the source tree. When you run "make check" in the source tree, what's acutally happening is cd build make check so it is actually running from build-dir context. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|