From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6452539580202614784 X-Received: by 10.46.22.16 with SMTP id w16mr1284646ljd.21.1502475634579; Fri, 11 Aug 2017 11:20:34 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.210.143 with SMTP id j137ls15030wmg.14.gmail; Fri, 11 Aug 2017 11:20:34 -0700 (PDT) X-Received: by 10.223.150.248 with SMTP id u111mr1204676wrb.1.1502475634265; Fri, 11 Aug 2017 11:20:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1502475634; cv=none; d=google.com; s=arc-20160816; b=ftFwIvu67gkCAY49gAAx7tGgsgeUHgWxBwJCbjl6fbhx9QsGzAqo4R9C4rhV3QsuRB QH5ZSrAcjt/hYQ0DE1tqLorooamcLAR+r2Ft8FcJbdXNp7+VfEEryoGZfIg7FtwuR5VJ vJekRzZgFz4xoFyvHjC2GLSCYEFZzOMJekgoyEQ79afzMes9Kv0H6s2V5fp9k4SADH1Z OuaAqb+rV3JqIJr1XwRQOR3sdDGjx2WX7KlWpFpGzqxHeDXdRtlKrfQN0/sdPiYtylgX Aj5miNPV93+DiVvOSQFX9fEPV8buphbDGTczlSsb2HkxYhs/D/8EI+aRLVPfbBxPNuW6 qRmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date :arc-authentication-results; bh=5lRbRtIxg/zsgDPZUUIcUL9nyRN+ywg6K+ARkNLtFVE=; b=BCgmTwo4LJE5dbnJcNBnF68DBY+CWPG0l6Tp1tLzvgRPRDrOqn5Osz9GOdsbASAPMw jEtlODHAugBKsC3P+1jgJjeKWuwK49rEWUk67IvuVngLuSF07AcUs9dW/W2kSE9BB0Py b6MRjbmg/U0HNAPgRu/IXc3pvoi4Divgmod/cZWpLSQG/VBKYLYl01NOsfdtBk7ywsLg jbmOe3+/ya5QQnYJSBy9UyDv/Z+r0i6AOMpYQeLptGE3yrj0mjWYbxPxdGI1a1xEFMDq llvWI6EgMRD2Pc9DFU1SpJRS1m+fIKqYkcOB4+8zi2p7Zgc6Bkrg4qYoHkUOWBgP2Yxa qtgg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id y189si79082wmc.0.2017.08.11.11.20.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 11:20:34 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.radix50.net ([206.167.44.205]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v7BIKVwM024112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 11 Aug 2017 20:20:33 +0200 Received: from yssyq.radix50.net (localhost [127.0.0.1]) by yssyq.radix50.net (8.14.4/8.14.4/Debian-8) with ESMTP id v7BIKPer004729 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 11 Aug 2017 20:20:25 +0200 Received: (from ibr@localhost) by yssyq.radix50.net (8.14.4/8.14.4/Submit) id v7BIKPY4004728 for isar-users@googlegroups.com; Fri, 11 Aug 2017 20:20:25 +0200 Date: Fri, 11 Aug 2017 20:20:25 +0200 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: Why does Isar build multiple configs in one OUTDIR? Message-ID: <20170811182024.GB3896@yssyq.radix50.net> Mail-Followup-To: isar-users@googlegroups.com References: <20170810091059.4244e529@md1em3qc> <15dcbe16a70.27ac.034a6b0541ed39b7fb4e17f4ac219eaa@ilbers.de> <20170810141754.68624a32@md1em3qc> <20170810130951.GB3259@yssyq.radix50.net> <20170810155237.760cfa40@md1em3qc> <20170810142501.GA4053@yssyq.radix50.net> <64b4e93c-c615-dd2c-128d-46ca737f9649@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64b4e93c-c615-dd2c-128d-46ca737f9649@siemens.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-TUID: bgCtfRXLy+19 On Thu, Aug 10, 2017 at 12:37:01PM -0400, Jan Kiszka wrote: > kas manages config dependencies that are under the same release regime > in a single file. It also provides a clean, archiveable build > environment, which is even more important with OE. > > If your production generates multiple variants from a single release, > there is surely a value in exploiting the new multiconfig feature of > bitbake. It's an optimization that can save a hand full of lines in your > CI script and likely quite a bit cycles of your CI server. I see it as > an added value. But as Isar is already wrapped around it, no longer > works without it (because that would mean duplicate maintenance), we > have to make sure to support it, including a better support in kas. Just to ensure we are talking about the same thing: BitBake's multiconfig feature is a means of building for multiple MACHINE + DISTRO configurations in a single run without having to deal with local.conf in between. Multiconfig and local.conf are completely equivalent and mutually interchangeable. BitBake and Isar support either without requiring the other, or both. In the same build dir, one can use local.conf for one bitbake run and multiconfig for another; the results are the same. We refer to multiconfig in the user manual to avoid lengthier textual description of editing local.conf. I agree with both of your points: * Combining two non-multiconfig builds via external tools would add maintenance overhead, and * kas's goal is CM of disparate entities under the same release regime rather than dealing with build issues. With kind regards, Baurzhan.