From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6452539580202614784 X-Received: by 10.99.63.141 with SMTP id m135mr7682020pga.128.1502371917186; Thu, 10 Aug 2017 06:31:57 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.107.181.147 with SMTP id e141ls10481297iof.33.gmail; Thu, 10 Aug 2017 06:31:56 -0700 (PDT) X-Received: by 10.200.55.72 with SMTP id p8mr7371955qtb.56.1502371916402; Thu, 10 Aug 2017 06:31:56 -0700 (PDT) Received: by 10.55.74.198 with SMTP id x189msqka; Thu, 10 Aug 2017 04:22:13 -0700 (PDT) X-Received: by 10.25.167.76 with SMTP id q73mr1402421lfe.25.1502364132484; Thu, 10 Aug 2017 04:22:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1502364132; cv=none; d=google.com; s=arc-20160816; b=u+6pPe71GSafM9Akf+N/YA83ifA3lzDaPXN4tBDzGPvqTRn71Kj6+071PTUV58AcBn zkdPd8O6RfB8bjLNslmqotTF6b42awLnnk2sfxoj7be0hdMDgwJA0kwOcUwUaINNkaAu zfVue2Um5uBsIIjSOdNMlm6Py3mpqKUu7K+q2vZLiXLFemdwNHkbhOajRcaAKrG6y4pr X2PfdsYHB4NQyiFmZEJMRwIYodpy8ouWvUITj1JF0mavNQdd6vyOrk3VlfdwgE535CU6 K5Pulom7tnbo1gD5HUB8UWY7HU+CgBCNUZr2E7OKjd8hl4ApgnPQLOh9MVyuz0i3hBYE 9XGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:subject:user-agent :references:in-reply-to:message-id:date:cc:to:from :arc-authentication-results; bh=JxpJAGI9xV4+1gApyaWe4d5EUYvbI1mVW24jQI4aTwU=; b=mD6ENsoqRFBQ2VJYOgEIqwy2Z4Z+zR1YYMsQI3mZaMIZcPpS9T1RMjp4DBQFvLSAf/ bN69u0jqNakHteZ+lgAqkHOYBFBim9KVu9LQkkL1mj6s1Xm0W+ey7y0UhXY7wjeUB639 74m97PIWh7zbuG8ctWigQIm1F4A0KGhmsmSEe/jxzdk4kg+A13tk7qK2JZyM1IJE0A2d WfTvRi0Y4yokg7Cl1WlyoNgn3HGCpTwPwDWkFMej1Kn451Q3i7eg8a9m2DnNelbrBuRD zhAkZGwh/2m6PWKvAhjpE8Zz2dH6oy4T/rJtYcfU1OUKR8axtjxRxji+na6K/pOQ/UZc On0A== 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 b125si1047806wmc.1.2017.08.10.04.22.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 04:22:12 -0700 (PDT) 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 [192.168.2.18] ([188.227.110.165]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v7ABM9jB006124; Thu, 10 Aug 2017 13:22:11 +0200 From: Alexander Smirnov To: Henning Schild , CC: "KISZKA, JAN" , Baurzhan Ismagulov Date: Thu, 10 Aug 2017 14:22:14 +0300 Message-ID: <15dcbe16a70.27ac.034a6b0541ed39b7fb4e17f4ac219eaa@ilbers.de> In-Reply-To: <20170810091059.4244e529@md1em3qc> References: <20170810091059.4244e529@md1em3qc> User-Agent: AquaMail/1.10.0-403 (build: 101000001) Subject: Re: Why does Isar build multiple configs in one OUTDIR? MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-TUID: xamJg8Zs9EFH Henning Schild 10 августа 2017 г. 10:09:06 написал: > Hey, > > at first i did not get the whole "extra-stamp" and ultra-deep directory > structure /DISTRO/ARCH/... But now i got it, Isar actually builds > multiple configs in a shared output directory. And in order to do so it > has to make sure that every single file does not create a name > collision. Coming up with extra-stamps and other funny stuff. It's not a "funny" stuff, it's how almost all the build systems works, including Yocto and OE. Please avoid "labels" in your comments. > > That way accidental reuse of any sort of build result is avoided. That's not true. Build for two machines with similar architecture and distro will reuse buildchroot and build results (if there are no machine specific stuff) > recipes inherit that complication and have to play along i.e. when > creating temporary files. Avoiding clashes is a very hard job to get > right throughout the whole system. Bitbake already provides *dedicated* way to do this, so we just use it. > > And at the end there seems to be absolutely no reuse of build results, Again, that's not true. You probably speak about current implementation, where we have sample machines to demontrate PoC. But Isar in general is a tool to build your product and main design requirements have come from real projects. > which would be the only justification for such madness. All Isar does > is come up with long names to avoid such reuse. That's the way how bitbake works. As I said, Yocto and OE uses the same approach. > > If you are building a kernel for two targets you use two O=, same is > true for cmake-projects and many other build systems out there. > > The only reuse of a build step i see at the moment is the git-clone of > Isar itself. Where are the gains that justify the complexity? If there > is a good reason, that i did understand yet, please answer to this > point and you can stop reading here. > > IMHO what should happen is: > - you clone your Isar once > - you clone your multiple target layers to _different_ dirs > - you run many (parallel) bitbakes in these dirs > - you _never_ build two targets in the same tree > - we drop all the complexity and do not force it down into > end-users I suppose that you are speaking about single use where you have specified machine and distro. One of the initial Isar requirement was to have possibility to support whole product, where product can have different platform and different base-system version. To release this product, you should build everything at once. Fetching various directories, setup them etc... bring unnecessary effort and complexity to whole product maintenance. Product is a single unit, that can't be split into the layers. And as bigger product machine/distro matrix, as much more complicated to support it. Alex > > I think there is the one use-case where you build two very same images > with the same ARCH DISTRO etc. and actually want to reuse. That > probably already works out of the box and if it does not, coming up > with long stamps and directory names that carry the shared attributes > does not help at all. > > Henning