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=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 80100C4320A for ; Tue, 27 Jul 2021 18:46:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6366860F6E for ; Tue, 27 Jul 2021 18:46:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231650AbhG0Sqo (ORCPT ); Tue, 27 Jul 2021 14:46:44 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:33286 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229453AbhG0Sqn (ORCPT ); Tue, 27 Jul 2021 14:46:43 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]:47884) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1m8S6C-004DYb-2A; Tue, 27 Jul 2021 12:46:40 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:57748 helo=email.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1m8S68-004Ncs-Ff; Tue, 27 Jul 2021 12:46:37 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Masahiro Yamada Cc: Arnd Bergmann , Linus Torvalds , Nick Desaulniers , Miguel Ojeda , Fangrui Song , Michal Marek , Linux Kernel Mailing List , Linux Kbuild mailing list , clang-built-linux , Geert Uytterhoeven , Christoph Hellwig , Nathan Chancellor References: <20210708232522.3118208-1-ndesaulniers@google.com> <20210708232522.3118208-3-ndesaulniers@google.com> <87r1fkizxl.fsf@disp2133> <87v94vg7vi.fsf@disp2133> Date: Tue, 27 Jul 2021 13:46:07 -0500 In-Reply-To: (Masahiro Yamada's message of "Wed, 28 Jul 2021 00:45:54 +0900") Message-ID: <87lf5rfvdc.fsf@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1m8S68-004Ncs-Ff;;;mid=<87lf5rfvdc.fsf@disp2133>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+3wQ5mLUbVDzV6nXI3HOEjKRRseKbKxYY= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v2 2/2] Makefile: infer CROSS_COMPILE from SRCARCH for LLVM=1 LLVM_IAS=1 X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Masahiro Yamada writes: > On Tue, Jul 27, 2021 at 11:16 PM Eric W. Biederman > wrote: >> >> Masahiro Yamada writes: >> >> > On Tue, Jul 27, 2021 at 5:27 AM Eric W. Biederman wrote: >> >> >> >> Masahiro Yamada writes: >> >> >> >> > On Wed, Jul 21, 2021 at 4:58 AM Arnd Bergmann wrote: >> >> >> >> >> >> On Tue, Jul 20, 2021 at 7:43 PM Linus Torvalds >> >> >> wrote: >> >> >> > On Tue, Jul 20, 2021 at 1:05 AM Masahiro Yamada wrote: >> >> >> > >> >> >> > We do most of the other heavy lifting in this area in Kconfig anyway, >> >> >> > why not add that compiler choice? >> >> >> > >> >> >> > Obviously it would be gated by the tests to see which compilers are >> >> >> > _installed_ (and that they are valid versions), so that it doesn't ask >> >> >> > stupid things ("do you want gcc or clang" when only one of them is >> >> >> > installed and/or viable). >> >> >> >> >> >> I don't see a good way of making Kconfig options both select the >> >> >> compiler and defining variables based on the compiler, since that >> >> >> would mean teaching Kconfig about re-evaluating all compiler >> >> >> dependent settings whenever the first option changes. >> >> >> >> >> >> I do have another idea that I think would work though. >> >> >> >> >> >> > Hmm? So then any "LLVM=1" thing would be about the "make config" >> >> >> > stage, not the actual build stage. >> >> >> > >> >> >> > (It has annoyed me for years that if you want to cross-compile, you >> >> >> > first have to do "make ARCH=xyz config" and then remember to do "make >> >> >> > ARCH=xyz" for the build too, but I cross-compile so seldom that I've >> >> >> > never really cared). >> >> >> >> >> >> The best thing that I have come up with is a pre-configure step, where >> >> >> an object tree gets seeded with a makefile fragment that gets included >> >> >> for any 'make' invocation. This would set 'ARCH=', 'CROSS_COMPILE', >> >> >> 'CC=' and possibly any other option that gets passed to 'make' as >> >> >> a variable and has to exist before calling 'make *config'. >> >> > >> >> > >> >> > There is no need to add a hook to include such makefile fragment(s). >> >> > >> >> > Quite opposite, you can put your Makefile (in a different filename) >> >> > that includes the top Makefile. >> >> > >> >> > >> >> > I think this is what people are already doing: >> >> > >> >> > >> >> > GNU Make looks for 'GNUmakefile', 'makefile', and 'Makefile' >> >> > in this order. >> >> > >> >> > >> >> > So, you can put 'GNUmakefile' with your favorite setups. >> >> > >> >> > >> >> > $ cat GNUmakefile >> >> > ARCH=arm64 >> >> > CROSS_COMPILE=aarch64-linux-gnu- >> >> > CC=clang >> >> > include Makefile >> >> >> >> Very weird. >> >> >> >> I just tested this and it does not work. >> >> I did this: >> >> >> >> $ cat GNUmakefile >> >> ARCH = alpha >> >> CROSS_COMPILE = $(arch-prefix alpha) >> >> include Makefile >> >> >> >> In one of my build directories and the main makefile simply does not see >> >> the value of ARCH or CROSS_COMPILE I set. I have confirmed that my >> >> GNUmakefile is being read, because everything breaks if I remove the >> >> include line. >> >> >> >> Does anyone have any ideas? >> >> >> >> Something so we don't have to specify all of these variables on the make >> >> command line would be nice. >> >> >> >> Eric >> > >> > >> > Worked for me. >> > >> > Could you tell me the exact steps you did? >> > >> > >> > This is my case: >> > >> > My kernel source tree is located at $HOME/ref/linux >> > alpha tool chains are located at $HOME/tools/alpha-10.1.0/bin >> > >> > >> > >> > I tried a simple GNUmakefile with 3 lines. >> > >> > You can see 'make' is building the alpha kernel >> > >> > >> > Please see below: >> >> Interesting. That appears to work if I don't specify a build directory. >> Once I specify a build directory with O= it does not work. >> >> When I am working on a change that affects multiple architectures >> I really want a build directory that is not my source tree so I can >> test small changes on multiple architectures without needing to rebuild >> everything. >> >> Eric > > > Ah, OK. > When you specify O= option, Kbuild will > invoke sub-make. > So you need to add 'export' to the > variables. > > Please see the following modified version. Yes. That does seem to work and be simpler. Is there any chance we can get the command that generates the Makefile in the build directory to include variables like ARCH and CROSS_COMPILE in the Makefile as well? Just so they don't need to be set by hand to the same value every time? Eric