From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6452539580202614784 X-Received: by 10.25.208.11 with SMTP id h11mr1279086lfg.19.1502367359169; Thu, 10 Aug 2017 05:15:59 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.104.131 with SMTP id d125ls1036608wmc.2.canary-gmail; Thu, 10 Aug 2017 05:15:58 -0700 (PDT) X-Received: by 10.28.126.196 with SMTP id z187mr79569wmc.20.1502367358802; Thu, 10 Aug 2017 05:15:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1502367358; cv=none; d=google.com; s=arc-20160816; b=hb0nWrRa9kPmqJl14Z4kowhHIrGxoP0WJ/fmUKlZRvsCuXy0UXQz9F3FaOmdCikfRB 4JT2qjbQWqBG9Gd6RIY6lyoZY/KdgoVEyOVwMfuv0YVw6IdNc+tBfvjcNY0OQsuPg2MQ j6xniEuNKRz4FqHQ+rrGEEGgFlwU5JeUQNRLD6xf3vs2VParpT2QGfG1VbawcDOzPRe5 JjxGOXEVjJwyub/4urtZX3g9Xg8NiK154GisqHVa9aGbPzcjU1sxXJFdQIcrF2SjbV6w fL+wBIKOl0f10oRTk7nqMd9RV6APCRBTVK59V7RkU3ZkqINUIQaYz6q1sSFra2uLv34N QegQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=11aIafNKpYZBKdzhgCkA7MGOahooNP38KZqJUptv51c=; b=Or3NLEk3cXrfC1vYW0pDS3dN0CnF8FP8wkD1TmHTKX3UYUMJ0kofQ/dorBeBQtYb1u 2n6wwHG4FM9hvijDOVch05uq+1BU2t6V20W18QYrhir4IXbvShcBelO7qeSriySOVbtA txhzYFMBj334lz5vJnlXTBkNHIsf3ouCCML9g//FImBSonzxxLXcONJYX+g5IbPunjtF Mk2Wp39scBlkWPjwyxo40i1WYBSvy2XR/ASNLfL/gavBbqSGfle12ENezIz6vgvBPzy0 kND52I0tzSEtWkEjfz4OVYglKcwwpDv7IXBkoFfze1mN/9piUuIf+yHSwwLFmrW8ZzVw O1Yg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id r65si1015061wmf.2.2017.08.10.05.15.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 05:15:58 -0700 (PDT) Received-SPF: neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id v7ACFwvn022928 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 Aug 2017 14:15:58 +0200 Received: from md1em3qc ([139.25.68.40]) by mail1.siemens.de (8.15.2/8.15.2) with ESMTP id v7ACFwAu020067; Thu, 10 Aug 2017 14:15:58 +0200 Date: Thu, 10 Aug 2017 14:17:54 +0200 From: Henning Schild To: Alexander Smirnov Cc: , "KISZKA, JAN" , Baurzhan Ismagulov Subject: Re: Why does Isar build multiple configs in one OUTDIR? Message-ID: <20170810141754.68624a32@md1em3qc> In-Reply-To: <15dcbe16a70.27ac.034a6b0541ed39b7fb4e17f4ac219eaa@ilbers.de> References: <20170810091059.4244e529@md1em3qc> <15dcbe16a70.27ac.034a6b0541ed39b7fb4e17f4ac219eaa@ilbers.de> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-TUID: WlLNrqS3vVfN Am Thu, 10 Aug 2017 14:22:14 +0300 schrieb Alexander Smirnov : > Henning Schild 10 =D0=B0=D0=B2=D0=B3=D1=83= =D1=81=D1=82=D0=B0 2017 =D0=B3. > 10:09:06 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: >=20 > > 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. =20 >=20 > 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. >=20 > > > > That way accidental reuse of any sort of build result is avoided. =20 >=20 > That's not true. Build for two machines with similar architecture and=20 > 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. =20 >=20 > Bitbake already provides *dedicated* way to do this, so we just use > it. >=20 > > > > And at the end there seems to be absolutely no reuse of build > > results, =20 >=20 > 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. >=20 > > which would be the only justification for such madness. All Isar > > does is come up with long names to avoid such reuse. =20 >=20 > That's the way how bitbake works. As I said, Yocto and OE uses the > same approach. >=20 > > > > If you are building a kernel for two targets you use two O=3D, 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 =20 >=20 > 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. > 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. > 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 >=20 > > > > 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 =20 >=20 >=20