From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6452539580202614784 X-Received: by 10.25.0.142 with SMTP id 136mr1309581lfa.31.1502348943983; Thu, 10 Aug 2017 00:09:03 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.4.141 with SMTP id 135ls2631665wme.9.gmail; Thu, 10 Aug 2017 00:09:03 -0700 (PDT) X-Received: by 10.28.109.146 with SMTP id b18mr1213456wmi.30.1502348943593; Thu, 10 Aug 2017 00:09:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1502348943; cv=none; d=google.com; s=arc-20160816; b=rbaSWGNfsV8IJDzhc42tUTJ58KxoQPmJzIpTcu8a7pp2ox/l3zVyfSogxoPe3fhdOg 4H0LLFLrE6pp9PJx6k8yBTO5NqJZMiLoqN66tiHQOmKvptf0ULDzS6D50gZ24en2sfJ5 KRgDwjhDtUsUtth6HYRAITH6NvDrDTBeDYaa6cuOjSrUZWeiPvpS6KmVflNgDYEUlAjh 7aFFXvqk2TeV4KUmfHQzgoecup7a1uCLvm6SvIVXyCGUisOigAsksOQrr8Jb7ma84m+M lHe6dvdoQiK/qDYscvDA0sqj86BNIeiDxtCN9N3UWGgQe2JbCfB2cb6lpvT5dSHqZ7Ic JWkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:message-id:subject:cc:to :from:date:arc-authentication-results; bh=Nk6iNKA0cvNmnljLIhc27rS1B4i2P/InLIPpj9/dgfU=; b=UPGgicvkRHO0iU9NWPHMayDly+bNC4xOIaNtJirKA7Kt1U5jLaFo8Z/WsxkKciHTld M5lTPEoKkvnpsuvJNC8/XeU1XLWjem715UWPeFrrSxWDSQq3t0hEi5vdsMRHW7GvbWos LhkqzfqhNbDVgUG0KSBXF37ec38gVeBv8DiCp7vRW64lmO21bivQ9fa3NXHUm6+Gplhe lheQtx4fXlR2bFrwHTXHno8bbJXAXpjpN18MEgs2zPd//PcQXkXeHwL1BS7yCsTYBSNs vzHUJjXKtcJsNvpLdQcbPRXRWf6D5TEbueapLEfKcYY3GAyGfrjYTTz7r57N/qK6SykT V1cw== 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 o62si1120655wmo.2.2017.08.10.00.09.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 00:09:03 -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 mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id v7A792K4009776 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 Aug 2017 09:09:03 +0200 Received: from md1em3qc ([139.25.68.40]) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id v7A792lD007573; Thu, 10 Aug 2017 09:09:02 +0200 Date: Thu, 10 Aug 2017 09:10:59 +0200 From: Henning Schild To: Cc: Alexander Smirnov , "KISZKA, JAN" , Baurzhan Ismagulov Subject: Why does Isar build multiple configs in one OUTDIR? Message-ID: <20170810091059.4244e529@md1em3qc> 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=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: 22aunQ3x+blW 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. That way accidental reuse of any sort of build result is avoided. All 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. And at the end there seems to be absolutely no reuse of build results, which would be the only justification for such madness. All Isar does is come up with long names to avoid such reuse. 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 recipes 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