From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6526857818487652352 X-Received: by 10.46.124.23 with SMTP id x23mr394340ljc.21.1520001751267; Fri, 02 Mar 2018 06:42:31 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.129.207 with SMTP id s15ls1087648ljg.10.gmail; Fri, 02 Mar 2018 06:42:30 -0800 (PST) X-Google-Smtp-Source: AG47ELswohyTmcIeuYYf6pxJ414Xr8GZ+wC1W9HKyzwle4IcroCxw6q4WR4cj4uY+v2yz5y0m0bB X-Received: by 10.46.85.25 with SMTP id j25mr390433ljb.43.1520001750685; Fri, 02 Mar 2018 06:42:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520001750; cv=none; d=google.com; s=arc-20160816; b=DXLG5YtUyNm0dyrFfiteFgT+NPNOOlJwNzgT7QBePG/a27qUnlWPt82XUaMk1nmgCK pZ8MI61J+AGuC+KZXX7YnFsrV402tEkKCbkyc60dPDCykcd8MjekgyxhhcVPJLR7lvgp GUHo5BhO/r9CM1cKIUT7uyNt1pPlvG8TRJ4H2VHWSqWYzsxnkBttUGstnYjEY3zI9AYU XRxN6VrZzpG0XMxSfGGKz9UwDOFUMrgvtXFUuY08h3HZ30zBsqaxNYWgrITewdzehH6+ py8+nRJQnl8LlD8whAZnZcf9VDWx30NuGlS3SfRJ8nIcA8CR8FN6skYOC5czkvSp6krA 5bZg== 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=O1TX/rNxfAbnaZ6LMBAJIFVYAAVhxK3wn7A86kC0yv4=; b=hk8hk5xmx9iC17x8N5JET5BLqZZDa1PClAdOayITncYQD7jtyZHMHhrDMheDhscJkL 2SwdkfTIG7X8KZWEziiiGtbVvBjpGKgHgX0q/SwWeIemw95gljtxUfYyO0oESoSScW/W HuyAT/vmE5irZ2pwukspwJLLHWoInSUL1bMY+MmF3/hOSECbkNzhwU8zcXyo+iItotbr RGWPvkL65jAUwMiEJSeohNnbzqVkF166ajoZf8h2YuIE/yKLk1TjP39gc5rXLd6I0In5 7FWRCjPpRfr0TII7k10HsNI1syX94w03FujUOR4fsU3eopbsyNutbRwo7PzJxQm+mQT4 eSJQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id 7si156012ljw.5.2018.03.02.06.42.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Mar 2018 06:42:30 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id w22EgTCj000564 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 2 Mar 2018 15:42:29 +0100 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id w22EgTCe017056; Fri, 2 Mar 2018 15:42:29 +0100 Subject: Re: [PATCH] Include error log of failing task in output To: Alexander Smirnov , 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> From: Jan Kiszka Message-ID: <7087f133-f016-2cef-5fa9-034086d8f5f8@siemens.com> Date: Fri, 2 Mar 2018 15:42:29 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <58c2463b-bfa9-7785-1b5f-6ae2ede05d3c@ilbers.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: 9Zh5qSkeR5VR 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? 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. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux