From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jU7YU-0007YN-8k for mharc-grub-devel@gnu.org; Thu, 30 Apr 2020 07:40:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60492) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jU7YS-0007UN-Fd for grub-devel@gnu.org; Thu, 30 Apr 2020 07:40:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jU7YJ-0007qW-Du for grub-devel@gnu.org; Thu, 30 Apr 2020 07:40:36 -0400 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]:46845) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jU7YI-0007pb-T2 for grub-devel@gnu.org; Thu, 30 Apr 2020 07:40:27 -0400 Received: by mail-wr1-x443.google.com with SMTP id f13so6431744wrm.13 for ; Thu, 30 Apr 2020 04:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=y9IJmYwFp9KmO+rLe3bhR21KA12Xt53V9s5dbBuiOgc=; b=2P1pdQ/qppcSUOYB7THFh5C6a3oWjQ53i0AioM77ebl3WGGbhqsPtglo6FBHX6QxhK 2WroK1tpf3nnmSyhajQcy48pGgePz3lxwNOmj4/yfcYamNwuCJA1HClun2Px2HKuWbnP rIodtFbOImcMttpBpOMVAbw7euHQ8u9FRQCblHegAn+FlE18qJ0Hk/5a9Xz8tajJxmpi ZKjB7RN4tYVg2ZaxPImETfcyOy7S8JUVK5IMUksUklp4LmFy6qy9Ygo5SEDhP69MLFic LACj3b1jqYqd8siYRSBvqs7n0MSuWz2z30s/enzQ+C09M2av/hb7JcJa2APq2IbXgvb1 +N3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=y9IJmYwFp9KmO+rLe3bhR21KA12Xt53V9s5dbBuiOgc=; b=Au7Jt6AOuNBDi4TsGVsxbC1JQmSLCzLtroo3RogWAN6VqpZhBf+/MhM8uLhfVg9qvP KTQjjcASIsrKJw3THKEGvh8zR9915jCpuTyHp4tVctWyzvkecLODtHUPovWgX3Bn1TwT LmR2TrpcykSMUGAqSSBsRCF5GYzB6A8LO9P+qd0dP13QzQSdDCKKZ25ZkbJKDDemuWqo mGctQ8sDDiI/qbA5NqCtCYyNzqVGRCX9mwThUQXvyWhZ3h7ME0V+o7tTw1zM2js2a0Jb mdiVwBQfj+cciSA2sSH782zUhrMhNe0B3N7Oo9AiQ0Jt7FYBmA/saZZsrSq5gW9K0UNG 6hGQ== X-Gm-Message-State: AGi0PuZjAZiXmws2+tJXIT+YLR5RLv/vKrB+B1o+QN28jDnox9MvBtRX Qr939ikixY89zWZzByDg9nVIrg== X-Google-Smtp-Source: APiQypJj65pJB4ffkI7ztrwhOnLKsedxY3JtYiyGyaW7/IA/LFE5Er6i1YxkgbhBznrs4iaUn05UKA== X-Received: by 2002:adf:ea48:: with SMTP id j8mr3682311wrn.108.1588246824632; Thu, 30 Apr 2020 04:40:24 -0700 (PDT) Received: from vanye ([2001:470:1f09:12f0:b26e:bfff:fea9:f1b8]) by smtp.gmail.com with ESMTPSA id p7sm3684537wrf.31.2020.04.30.04.40.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Apr 2020 04:40:24 -0700 (PDT) Date: Thu, 30 Apr 2020 12:40:21 +0100 From: Leif Lindholm To: Daniel Kiper Cc: grub-devel@gnu.org, eschwartz@archlinux.org, floppym@gentoo.org, javierm@redhat.com, olaf@aepfle.de, phcoder@gmail.com, pjones@redhat.com Subject: Re: [PATCH v2 3/4] INSTALL/configure: Update install doc and configure comment Message-ID: <20200430114021.GR21486@vanye> References: <20200403124503.12779-1-daniel.kiper@oracle.com> <20200403124503.12779-4-daniel.kiper@oracle.com> <20200407111609.GM14075@vanye> <20200410120548.wry6gvmjhr6paomw@tomti.i.net-space.pl> <20200420130432.GH14075@vanye> <20200421145525.d5pjzxewgiyxplgo@tomti.i.net-space.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200421145525.d5pjzxewgiyxplgo@tomti.i.net-space.pl> User-Agent: Mutt/1.10.1 (2018-07-13) Received-SPF: pass client-ip=2a00:1450:4864:20::443; envelope-from=leif@nuviainc.com; helo=mail-wr1-x443.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2a00:1450:4864:20::443 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 11:40:37 -0000 On Tue, Apr 21, 2020 at 16:55:25 +0200, Daniel Kiper wrote: > > > > > You need to use following options to specify tools and platforms. For minimum > > > > > version look at prerequisites. All tools not mentioned in this section under > > > > > @@ -182,28 +182,31 @@ corresponding platform are not needed for the platform in question. > > > > > > > > > > - For host > > > > > 1. --host= to autoconf name of host. > > > > > - 2. CC= for gcc able to compile for host > > > > > - 3. HOST_CFLAGS= for C options for host. > > > > > - 4. HOST_CPPFLAGS= for C preprocessor options for host. > > > > > - 5. HOST_LDFLAGS= for linker options for host. > > > > > - 6. PKG_CONFIG= for pkg-config for host (optional). > > > > > - 7. Libdevmapper if any must be in standard linker folders (-ldevmapper) (optional). > > > > > - 8. Libfuse if any must be in standard linker folders (-lfuse) (optional). > > > > > - 9. Libzfs if any must be in standard linker folders (-lzfs) (optional). > > > > > - 10. Liblzma if any must be in standard linker folders (-llzma) (optional). > > > > > + 2. CC= for gcc able to compile for host and target. > > > > > > > > But this is incorrect? Apart from where HOST == TARGET? And goes > > > > against the example updated above. > > > > Am I missing something? > > > > > > It is correct, CC applies for host and target... > > > > So why do we have TARGET_CC and HOST_CC? > > > > My understanding is: > > - CC sets the default compilet binary, used for BUILD, HOST and TARGET > > unless overridden for each of these. > > Nope, just HOST_CC and TARGET_CC. You can override CC using TARGET_CC and > HOST_CC respectively. Order in configure command line does not matter. I wasn't suggesting command line order mattered. > > - The value of BUILD_CC is used as default for HOST_CC unless > > HOST_CC is explicitly specified. > > Nope, it is not. > > > - The value of HOST_CC is used as the default for TARGET_CC, where *it* > > is not explicitly specified. > > Nope, it is not. > > > Either my understanding here is incorrect, or these changes make the > > text more rather than less misleading. > > Sorry but I am not sure what is unclear after my changes. OK, I concede configure.ac completely ignores the value of CC for setting BUILD_CC. It tests for a hard-wired set of commands (which seems weird to me, but some googling suggests that is indeed default behaviour - I guess overriding the BUILD_ toolchain is the *least* common use case). But let me rewind: configure scripts support separate concepts of BUILD, HOST and TARGET to permit things like cross-compiling a tool on an AMD64 box (BUILD) to run on an armhf box (HOST) to generate images to run on SPARC (TARGET). CC is traditionally used to override just using the first "gcc" command to find a (apparently HOST_) toolchain. But if I set both HOST_ and TARGET_ options for my build, I expect the target to be built using the TARGET_ toolchain. If I specify CC and TARGET_CC, I expect the target to be built with TARGET_CC. Which is thankfully also what happens in reality. However, the proposed change now says that HOST_CC sets the host and target compiler and that TARGET_CC sets the target compiler. This is not even self-consistent. I get what the change is trying to say, but I feel it is only adding confusion. I think the same thing could be adequately conveyed by adding something along the lines of: "If no target options are given, these will default to be the same as the host options." immediately below the - "For target" line I don't think adding description of CC/CFLAGS to target section improves clarity. If CFLAGS should be separately speficied, I think that makes more sense next to HOST_CFLAGS. And I think if we're changing this, we should add an entry for HOST_CC - or add that to the existing CC option. Regards, Leif