From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6526857818487652352 X-Received: by 10.36.211.20 with SMTP id n20mr1548493itg.24.1520003197179; Fri, 02 Mar 2018 07:06:37 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.36.39.211 with SMTP id g202ls372625ita.7.canary-gmail; Fri, 02 Mar 2018 07:06:36 -0800 (PST) X-Google-Smtp-Source: AG47ELt5eQIKojvC9nLM2ChW4v5W8+NJRlEqGFU3rTm5CTilXtTB87wdzSeq3ImIqH0NJfbJf5V7 X-Received: by 10.36.95.209 with SMTP id r200mr1602898itb.54.1520003196676; Fri, 02 Mar 2018 07:06:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520003196; cv=none; d=google.com; s=arc-20160816; b=GHjYKBO18DUYpHp6tBJoLvfWW/WBpxlzWoms1NQr0yzBsFR1WmxI5WJnnhmF1ZeR58 7kfU6o/LiXOjUMq5PyxLktfPg4SZ9cnduaSi76KAjAIpZxk3gBUovQIF/SUcL6nxUujX 9nxgeghC80E5yrilSsTDx7pQhBILR+im9lfUh3Gjzd7i2I/BWodseoNodfkfKb/q1ld4 IxWUHGNCKwfI7iYKyIqhyV7654yEcQQ3dSk7cDxc4vJZDmCYUjIMBPwOyOunzoYcSCTC BWyqgDAhkMVyHpfjqJbZahTnIn5zt/uwmpTq9ctrhi6s5qjXz+XPDVGmnG2byN/muwyd BKNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :arc-authentication-results; bh=Wy6jsXKpA1mPOVgvd9PerMWoRdOdpfeYgIEw1mjaB5M=; b=otBivKqUck9ZiUHpCIaU4rly9dg0DH292zcbLLK96TI1eCQ+ewjwLwpGDWGG1dbGbF xUWAtGxdoepp2S5FHhsRCnrIl3HAkSM1GqiZchECDYBfVFu95jqGK2/LV/H3eGP8twPm vuxm1QnSgXq/et9bjD3DImYTwjruO8wHDkYejhFrjGDG6dgHsEl6AXs/fWDrWlT500fc ItglCfSJgZdF+8UfbVRi5vWiiqSYAj7x2GrX4+wEViubwJptTG4Xj2O1LI/IFtTYu/9Y ZYd2YqReJ+OimCD01y9Ka3i5NKsp2o88ACbsJ4iM5QlaeR2/7z8ONXWJ38Ow0ZvYahQt 0ZuQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id l8si715746iog.3.2018.03.02.07.06.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Mar 2018 07:06:36 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Received: from [10.0.2.15] ([188.227.110.165]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w22F6Vpn007806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 2 Mar 2018 16:06:33 +0100 Subject: Re: [PATCH] Include error log of failing task in output To: Jan Kiszka , isar-users References: <955aab45-bca0-7458-e3d6-a90616d2cbd7@ilbers.de> <34f64f37-d5ec-5135-96aa-5e1a99d6c264@siemens.com> <5c9f3414-e119-53be-5283-9278a8637bb4@ilbers.de> <58c2463b-bfa9-7785-1b5f-6ae2ede05d3c@ilbers.de> <7087f133-f016-2cef-5fa9-034086d8f5f8@siemens.com> From: Alexander Smirnov Message-ID: <28d8adf1-001b-65b1-6961-b399ae11c919@ilbers.de> Date: Fri, 2 Mar 2018 18:06:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <7087f133-f016-2cef-5fa9-034086d8f5f8@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: FYT4XTBQ46XN On 03/02/2018 05:42 PM, Jan Kiszka wrote: > On 2018-03-02 14:57, Alexander Smirnov wrote: >> >> >> On 03/02/2018 04:24 PM, Jan Kiszka wrote: >>> On 2018-03-02 14:04, Alexander Smirnov wrote: >>>> >>>> >>>> On 03/02/2018 03:46 PM, Jan Kiszka wrote: >>>>> On 2018-03-02 13:43, Alexander Smirnov wrote: >>>>>> >>>>>> >>>>>> On 02/26/2018 04:41 PM, Jan Kiszka wrote: >>>>>>> From: Jan Kiszka >>>>>>> >>>>>>> Particularly helpful in CI environment, but it also saves many manual >>>>>>> log dumps. >>>>>>> >>>>>>> Signed-off-by: Jan Kiszka >>>>>>> --- >>>>>>>     meta/conf/isar-bitbake.conf | 2 ++ >>>>>>>     1 file changed, 2 insertions(+) >>>>>>> >>>>>>> diff --git a/meta/conf/isar-bitbake.conf >>>>>>> b/meta/conf/isar-bitbake.conf >>>>>>> index b49386c..8a1d86b 100644 >>>>>>> --- a/meta/conf/isar-bitbake.conf >>>>>>> +++ b/meta/conf/isar-bitbake.conf >>>>>>> @@ -42,6 +42,8 @@ BB_STAMP_POLICY ?= "full" >>>>>>>       BB_NUMBER_THREADS ?= "${@bb.utils.cpu_count()}" >>>>>>>     +BBINCLUDELOGS ??= "yes" >>>>>>> + >>>>>> >>>>>> Is there any specific reason of using the weakest assignment here? The >>>>> >>>>> Because all tuneable confs are included after this statement. >>>> >>>> In my understanding, tuneable confs should not contain "?" marks in >>>> assignment, because they specify concrete configuration. :-) That's what >>>> I see, for example, in local.conf file. >>>> >>>>> >>>>>> whole file contains "?=" only, for me this looks enough here too. >>>>> >>>>> That's likely a bug to be fixed separated. >>>> >>>> What is your overall policy for assignment in this case? >>> >>> Upstream: Look at oe-core's bitbake.conf. It seems to do weak defaults >>> pretty consistently for stuff that might be set via ?= in other confs. >>> >> >> Yeah I saw it, but who could overwrite BBINCLUDELOGS? For me this option >> has the same level as BB_NUMBER_THREADS or PARALLEL_MAKE. So IMHO the >> only local.conf file is the place to overwrite it. >> >> I've looked into OE/Yocto bitbake.conf, and I think there is the >> following logic that in my opinion makes sense: >> >>  - Global build system settings are mostly defined using "?=", because >> they should be overwritten in some global file like local.conf only. >> Tuning this parameter in machine/*.conf is definitely bad idea. >> >>  - Settings, related to produced results, like DISTRO, MACHINE, LDFLAGS >> etc. are defined using "??=", because such things could be overloaded >> from machine/distro config files, from generic recipes etc. >> >> So I still propose to use "?=" here. > > > Is there a well defined ordering when multiple ?= follow each other? > Which one wins, the first or the last? > The first one. But user should not use "?=" for such variables like: BBINCLUDELOGS, BB_NUMBER_THREADS etc. If you overwrite default system settings, you completely understand what you are doing and hard assignment should be used. > Often you have the desire to provide a default in some included config > in case some other include does not define a final value. We are at the > top level here, so we should step back from such things and use a weak > default. Don't really understand the usecase of cascading exactly BBINCLUDELOGS several times. This option doesn't affect build content, so the only one place to overwrite it - is your local.conf. So there are no other included configs for now, and I believe in future also. Anyway, I could stay with this. Alex