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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 957DBC433DF for ; Tue, 26 May 2020 16:57:44 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (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 6AFF820776 for ; Tue, 26 May 2020 16:57:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6AFF820776 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jdct8-00063G-1T; Tue, 26 May 2020 16:57:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jdct7-00063B-Gt for xen-devel@lists.xenproject.org; Tue, 26 May 2020 16:57:13 +0000 X-Inumbo-ID: f1465156-9f71-11ea-a67a-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f1465156-9f71-11ea-a67a-12813bfff9fa; Tue, 26 May 2020 16:57:12 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Ed4zbgttKkGzIfaAMvpWOXhlhTutbzcPEmuDnZM8pbCvXqxKC4m9CSxobFnlIikgvFyroi9lQO cIgQ2WhxACHkxlhldfZXtDV0TRsJkHQT3Mnre6bKvtu4ABZzaL9M4ueaxcK55zf9cNCmhjG7dZ cpmm+vyxv3TdptcpeZTgzOIPgnV8avyYTQF23ztnakf7YA8myDfIHWDcNqBdtUkqfIYGPtGUsj YjnBWodCwkiP7xVXXMpxfjFn9VWFWpHy00YQ7z8W7fRmJL97Kd6HwRHesM5BWqtfdFLxB/wYj+ yCo= X-SBRS: 2.7 X-MesageID: 18829419 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,437,1583211600"; d="scan'208";a="18829419" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <24269.19042.534647.23671@mariner.uk.xensource.com> Date: Tue, 26 May 2020 17:57:06 +0100 To: George Dunlap Subject: Re: [PATCH 3/5] libxl: Generate golang bindings in libxl Makefile In-Reply-To: References: <20200522161240.3748320-1-george.dunlap@citrix.com> <20200522161240.3748320-4-george.dunlap@citrix.com> <24269.8019.97048.52370@mariner.uk.xensource.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , "xen-devel@lists.xenproject.org" , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" George Dunlap writes ("Re: [PATCH 3/5] libxl: Generate golang bindings in libxl Makefile"): > tools/Makefile:subdirs-all is implemented as a non-parallel for loop executing over SUBDIRS-y; tools/golang comes after tools/libxl in that list, and so tools/golang:all will never be called until after tools/libxl:all has completed. This invariant — that tools/golang/Makefile:all must not be called until tools/libxl/Makefile:all has completed must be kept regardless of this patch, since xenlight/Makefile:build depends on other output from tools/libxl/Makefile:all. I had not spotted this aspect of the situation. But the toplevel Makefile is parallel. I think this means that make -C works between different directories in tools/. Provided no-one says `make all install' (which is a thing that people expect to work but which is already badly broken). > So as long as nothing else calls tools/libxl:all or tools/libxl:idl-external, this should be safe. We could add a comments near xenlight/Makefile:idl-gen saying it must only be called from libxl/Makefile:idl-external; and to libxl/Makefile:idl-external saying it must not be called recursively from another Makefile. So, err, I'm sold on the original patch, I think. Acked-by: Ian Jackson I'll answer your other comments anyway: > > Alternatively, move the generated golang files to tools/libxl maybe, > > and perhaps leave symlinks behind. > > Would that result in the files being accessible to the golang build tools at https://xenbits.xenproject.org/git-http/xen.git/tools/golang/xenlight ? If not, it defeats the purpose of having the files checked into the tree. Yes. git can convey symlinks. (I'm assuming that the golang build tools fetch the git objects and do git checkout, rather than trying to download individual raw files from gitweb...) > > Or convert the whole (of tools/, maybe) to nonrecursive make using eg > > subdirmk :-). https://diziet.dreamwidth.org/5763.html > > This isn’t really a practical suggestion: I don’t have time to refactor the entire libxl Makefile tree, and certainly don’t have time by Friday. Yes, it wasn't a serious suggestion. Sorry that that apparently wasn't clear. Regards, Ian.