From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6452539580202614784 X-Received: by 10.129.112.72 with SMTP id l69mr7376888ywc.12.1502371916811; Thu, 10 Aug 2017 06:31:56 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.107.12.201 with SMTP id 70ls6794044iom.22.gmail; Thu, 10 Aug 2017 06:31:56 -0700 (PDT) X-Received: by 10.200.49.248 with SMTP id i53mr6974856qte.117.1502371916402; Thu, 10 Aug 2017 06:31:56 -0700 (PDT) Received: by 10.55.74.198 with SMTP id x189msqka; Thu, 10 Aug 2017 05:46:58 -0700 (PDT) X-Received: by 10.25.81.199 with SMTP id g68mr1286738lfl.21.1502369218303; Thu, 10 Aug 2017 05:46:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1502369218; cv=none; d=google.com; s=arc-20160816; b=0ePrUkyq6nlGQKqAGB+ZbeFrY6ggUcYeqznp3TMEGhWQX8PY8yAEFsiOOENCM52AzS RMiLuismxkZKW0XQPD9A6gZVhs7ZK5QvEztG3NzvLkFqe2U8yHAxxmvnP3WvLK0NfSKi TpgZkDCLeZPOLCPXp4z9V6QdeKHixvTH8izyQab39yhpDn8mWHUuE4aV+XOuOSTSJJmM 6lYZIFDHFurBBJlHRMj00jrWGYtQ8KytL/djL32ExwvkDNalSAuthYECCrKUwA7E+BNU rd3TW+nu03JchFaMAqR+sbl8/im7Rwi/ACALtTicjFAgc2ZGzJP34mFVYlj3YE6ugn1x US3w== 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:cc:to:subject :arc-authentication-results; bh=q7ux4y3bNvi3jMrlM0hwCRgInxbBvx3bCuElD9vjOEU=; b=0FsjFqIiL5LnA1iZspP6TgbLDPxs+W1hFSGGFnWIgNLEoceTOGqVSIT3b0yxOD+UMd cuCtzQPsMKsspEETa1wuI4RRqEsSFpHA5eiSj3hOimohlBtvM75G1vA65PFJGM7KFrux PB4VrMxc48l4F7C+51/fn9dm8nheom+cdBULg+ND5rRHzEpp9Bw+b8/pNrIP6kz6suld 83cqyrpX+85xh0AP8WhZtIvHPw1vqRYB9kUtV4Bv05N+ZmbhJMT8KJTcNNodcf0FjH3A 99pAj3bPNgvKMCD5RpjpohItbsV2NMbHouFU99QID2u5AcVmlL3miC/E0iEZoSNJb7ug Fx1g== 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 j199si536986wmj.4.2017.08.10.05.46.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 05:46:58 -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 [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 v7ACkt37006374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Aug 2017 14:46:56 +0200 Subject: Re: Why does Isar build multiple configs in one OUTDIR? To: Henning Schild Cc: isar-users@googlegroups.com References: <20170810091059.4244e529@md1em3qc> <15dcbe16a70.27ac.034a6b0541ed39b7fb4e17f4ac219eaa@ilbers.de> <20170810141754.68624a32@md1em3qc> From: Alexander Smirnov Message-ID: Date: Thu, 10 Aug 2017 15:46:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170810141754.68624a32@md1em3qc> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: /3IwqjGSbFyO On 08/10/2017 03:17 PM, Henning Schild wrote: > Am Thu, 10 Aug 2017 14:22:14 +0300 > schrieb Alexander Smirnov : > >> 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) > > Is that the point i covered in the last section? > >>> 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. > > Please answer this key question, with examples. > >>> 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. > > What is a "product"? I would say the Iphone is a product and you would > have 7 configs for its respective versions. I can see how you would > want to build those 7 in one tree. What you are suggesting is the whole > "product line" of Apple in one "product", from the smalles ipod to the > workstations. Product is what you sell in the market. From technical point of view, product can be described as a set of 3 parts: hardware, base system, application layer. In typical cases, you maintain the application layer only, the other things are provided by suppliers (internal or external). Releasing new version of your application layer forces you to provide software update for whole product-line officially supported. > >> 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. > > Wrap the building with a script, i.e. have a look at kas. Why each Isar user should wrap such scripts for each project, when this can be a part of basic functionality? Does this really make Isar less complicated? I'd agree with your concern in context, that this design can be overhead for case where we have *single* machine and *single* distro version. But initial Isar idea was to support products with matrix of configurations. > >> 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. > > How can one atomic thing have multiple architechtures, i do not get > that point at all! Is your product a whole building or airplain? Even > if it was it needs to be modular ... > > Henning > >> 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 >> >> > -- With best regards, Alexander Smirnov ilbers GmbH Baierbrunner Str. 28c D-81379 Munich +49 (89) 122 67 24-0 http://ilbers.de/ Commercial register Munich, HRB 214197 General manager: Baurzhan Ismagulov