Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3773131ybb; Tue, 31 Mar 2020 11:41:31 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsjpYGSzr6MF+cDAiFcsf+Fqatvqt1Ww2Jut/GZtQPD7gQ6OVP6Y9Fu+eSoN/YOpDLI4vuZ X-Received: by 2002:a9d:178a:: with SMTP id j10mr13704931otj.182.1585680091605; Tue, 31 Mar 2020 11:41:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585680091; cv=none; d=google.com; s=arc-20160816; b=eX11AOH9E6cK1jwMood6+gTPcIBGk2igpQh8V1r5o47cW9JMGGpHfjLs8eGht21CSF QvVyzU4WW+GlQ+bbq0/jaZmDQqCA1JKDEy47DULNfFRd8B0aZJSJPEmpjIKt1E+hNm8e vNVL6ZsvUoxe+Vv4O8PiVUHfbKzXuHL4yC/VeY7ODJ0hhpyxC6hiOVDAdu2rjEYatdmE yRIrX4vlVWewYRbHQDQbdo1IAQ5ImZOtqb8/8njmfyl7k0nEOEbSc+uiw3FOJonhMumx 7I2wT62dXNwFVgcH+jqzXo1FqFaOFng4rUh/akUSZcHKoC3BasSrg6MfmLppRNftYbUG 9IDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=SHbm0jKU3Qf278+OR+FaPiESB5wVrt4XPcJB5hVkN60=; b=Tgo2BAPtfkLo/LHE9il80oVFm2mmkER+NJ7OQ5o73kbJ0dap6TpIpfVKp0VlS33G5G 7O4ShDTDOOPFhF9h3fYZTyBAQ4ZErh1ap9mbtahXJ0dfiPjdKi9OOlg9FVhs7484Ep2S HPl+F4+fBbep/sNFCRiMM8pazN2djgT768Q536uABydzPrN2qWtyQpUd9LkAmIUZcoIe SzOmqaer6pl9A1FPgCBQOsrHSzK90QxnsfaIKoJEfTljHvKJIVYmZhQO2dyzF80N9Ar2 FN1ZrvKb823baVl4+M2Us5bMCyozx41oJPqXLVnxG4DChNYoVmaq6k6OG/OHQusQxFy2 w75g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=gzp6usWw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l14si7934444ooe.48.2020.03.31.11.41.18; Tue, 31 Mar 2020 11:41:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=gzp6usWw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726548AbgCaSjl (ORCPT + 99 others); Tue, 31 Mar 2020 14:39:41 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:34279 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726208AbgCaSjl (ORCPT ); Tue, 31 Mar 2020 14:39:41 -0400 Received: by mail-pg1-f194.google.com with SMTP id l14so3604230pgb.1 for ; Tue, 31 Mar 2020 11:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SHbm0jKU3Qf278+OR+FaPiESB5wVrt4XPcJB5hVkN60=; b=gzp6usWwaOaYw59h8kIkVvyKdywVJuZ3NJfd1wircVTJnmvJhRmmVES8Jd/uck+Hcj ihI+fmLC9r0Fv+rle/XhuJNKG4Dhm3WrAd9b6Gcf22o9h5fjVyDFOPWL42kso1BjM5Ur Aq4LNX5vpl4l7pUG4lJYmg9K8myTVDTRz/3Cb/ZLxtzl1N75YXTh7ZwYDQZnWSqTNFQ2 0UxAU/6LqBe2UKoLTLyqYslEIfZlCWGgoUmL1E1HN9bAfYM2qIEUaUNBIbaIBGOWuojs YP2RcDR7MZJsyWmuOefOtp80GgmLixZ4eEUTEQOEyE4nnUkCANBzKbPpgq7dBHmtW9D1 N1yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SHbm0jKU3Qf278+OR+FaPiESB5wVrt4XPcJB5hVkN60=; b=XODclHaD8Eue349bGJ4BUiCwHx95IHU19r1Sb+RgPZpCU1G4iIDhnukeLhF64tyVbZ ePt40Mv7XGMYyy+tpFSIg3zQBi9H7fUmo5g4Fs0amnJJypPYdn1OY8JGhRh40gaeWzdb s68XSqzdO/y0QmMDOwTSXRrcv1IeC9pPxQYxMg5ffZx6+l+fLIZYtH7ylxoHTi3eTNfO b+VnMEQTEUjzP5BUIl5lc1QJ5CXBvbBnyLh8I71sCws0czUaOzmXHoDzsvpKRm59/+4k UQ3rgZaI/V0pVdSV5eToPXFN3qO9xgzp30hIQCE1zLyNNHfzUj3tG1/1pwjtq7LlZAxf /eqw== X-Gm-Message-State: ANhLgQ2N00qLvmzpS+iuFS4xAM1vA97n/0heNn7BwZg4Pepzpm5hALvb 6gENJKyY6uycA5cO8BW7P/eTYch+HELiUMk8GKQDrASKskY= X-Received: by 2002:a63:4e22:: with SMTP id c34mr19536884pgb.263.1585679979479; Tue, 31 Mar 2020 11:39:39 -0700 (PDT) MIME-Version: 1.0 References: <20200317202404.GA20746@ubuntu-m2-xlarge-x86> <20200317215515.226917-1-ndesaulniers@google.com> <20200327224246.GA12350@ubuntu-m2-xlarge-x86> <20200330190312.GA32257@ubuntu-m2-xlarge-x86> In-Reply-To: From: Nick Desaulniers Date: Tue, 31 Mar 2020 11:39:27 -0700 Message-ID: Subject: Re: [PATCH v2] Makefile.llvm: simplify LLVM build To: Masahiro Yamada , Nathan Chancellor Cc: clang-built-linux , Linux Kbuild mailing list , Linux Kernel Mailing List , Sandeep Patil Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 30, 2020 at 11:25 PM Masahiro Yamada wrote: > > On Tue, Mar 31, 2020 at 4:03 AM Nathan Chancellor > wrote: > > > > On Mon, Mar 30, 2020 at 11:58:19AM -0700, Nick Desaulniers wrote: > > > On Sat, Mar 28, 2020 at 6:57 PM Masahiro Yamada wrote: > > > > > > > > I also had planned to provide a single switch to change > > > > all the tool defaults to LLVM. > > > > > > > > So, supporting 'LLVM' is fine, but I'd rather want this > > > > look symmetrical, and easy to understand. > > > > > > > > CPP = $(CC) -E > > > > ifneq ($(LLVM),) > > > > > > Yes, a simple if statement is much simpler than the overly complex patch I had. > > > > > > > CC = $(LLVM_DIR)clang > > > > > > Do we need $LLVM_DIR? Shouldn't users just have that in their $PATH? > > > > > > Also, I think we need to support suffixed binaries, as debian > > > distributes these with version suffixes, as Nathan points out. Or do > > > the debian packages install suffixed binaries AND path versioned > > > non-suffixed binaries? > > > > I think the idea here is that ultimately, the suffixed versions of clang > > that Debian has in /usr/bin are symlinks to binaries in > > /usr/lib/llvm-#/bin; as a result, a user could say > > LLVM_DIR=/usr/lib/llvm-#/bin/ and all of those tools would be picked up > > automatically. I am not really sure what is better. $ sudo apt install clang-8 $ which clang-8 /usr/bin/clang-8 $ ls -l `!!` /usr/bin/clang-8 -> ../lib/llvm-8/bin/clang $ ls /usr/lib/llvm-8/bin Ok, so Nathan, it looks like we don't need the version suffixes. Instead, we can be more explicit with our $PATH, and only add the above (and bintutils). I was thinking supporting the suffix was required for our CI, but it seems like maybe not. > I periodically build the latest llvm from the trunk, > and install it under my home directory. > So, I just thought it would be useful to > allow a user to specify the llvm directory. > Of course, I can do the equivalent by tweaking PATH, but > I hesitate to make the non-released version my default. Respectfully, I strongly disagree. This should be handled by modifications to $PATH, either by your shell's .rc file when you always want it, or exported for a session when you want it, or prefixed to an invocation for the duration of that command. We should not have a new variable just for the path of a few tools. Rather than `make LLVM_DIR=~/llvm-project LLVM=1`, you can do `PATH=$PATH:~/llvm-project make LLVM=1`. (or export it manually or via your shell .rc, depending on how comfortable you are with that version). > Having both LLVM_DIR and LLVM_SUFFIX seems verbose. I agree, so maybe just LLVM=y, and we can support both non-standard locations and debian suffixes via modifications to PATH. > > In fact, the debian provides multiple versions of GCC. > For example, my machine has > > masahiro@pug:~$ ls -1 /usr/bin/gcc-* > /usr/bin/gcc-4.8 > /usr/bin/gcc-5 > /usr/bin/gcc-7 > /usr/bin/gcc-ar > /usr/bin/gcc-ar-4.8 > /usr/bin/gcc-ar-5 > /usr/bin/gcc-ar-7 > /usr/bin/gcc-nm > /usr/bin/gcc-nm-4.8 > /usr/bin/gcc-nm-5 > /usr/bin/gcc-nm-7 > /usr/bin/gcc-ranlib > /usr/bin/gcc-ranlib-4.8 > /usr/bin/gcc-ranlib-5 > /usr/bin/gcc-ranlib-7 > > But, nobody has suggested GCC_SUFFIX. > > So, I guess CROSS_COMPILE was enough to > choose a specific tool version. Or no one was testing specific versions of gcc with more than one installed. I can ask the KernelCI folks next week if this is an issue they face or have faced. -- Thanks, ~Nick Desaulniers