From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id jwdvMOAcImA/VQAAWB0awg (envelope-from ) for ; Tue, 09 Feb 2021 00:25:52 -0500 Received: by simark.ca (Postfix, from userid 112) id B90251EF4F; Tue, 9 Feb 2021 00:25:52 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 16BC41E789 for ; Tue, 9 Feb 2021 00:25:51 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4507D398B145; Tue, 9 Feb 2021 05:25:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4507D398B145 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1612848350; bh=FGw8YtIaumHeLBiANcHekOfpyCCAXTY3ZtcAPj/qvZY=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=PLwNHLylY0HlRA/BfuiFXsr12x9vg1AxDi37yVaQiuUuthX+l3Qe/uzT1xIxNMHBd 4jXL84tA6vkUZB5HY2xwP8nrmXIpsnumGOesA7FIib3QAE9NxeHtzfsRZfAQHW9YdO mw++iNYqgIGDw6C+In7chTBvp69lTnivUa+6AIGk= Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 3CF39393C840 for ; Tue, 9 Feb 2021 05:25:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3CF39393C840 Received: from vapier (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 38896340CFA; Tue, 9 Feb 2021 05:25:45 +0000 (UTC) Date: Tue, 9 Feb 2021 00:25:44 -0500 To: Andrew Burgess Subject: Re: [PATCH] sim: testsuite: push $arch out to targets Message-ID: Mail-Followup-To: Andrew Burgess , gdb-patches@sourceware.org References: <20210117160945.1362-1-vapier@gentoo.org> <20210118095201.GN265215@embecosm.com> <20210121092253.GW265215@embecosm.com> <20210131105438.GQ265215@embecosm.com> <20210208121245.GG265215@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210208121245.GG265215@embecosm.com> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mike Frysinger via Gdb-patches Reply-To: Mike Frysinger Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 08 Feb 2021 12:12, Andrew Burgess wrote: > I don't really understand what your end vision is. my ultimate end point has a number of features: * one sim/configure script (no subdir configures) * no recursive make (e.g. sim/Makefile.am includes sim//*.mk) * a single `run` program that optionally supports all arches * removal of all target tuple checking everywhere (other than the sim/configure.ac for selecting which ports to enable) * a parallel testsuite * no dejagnu * uses automake's test harness * all ports using common/ modules for functionality instead of their own ad-hoc implementations (e.g. memory from sim-core instead of the port doing its own malloc) the benefits of this: * faster build & test for all configurations * support for --enable-targets=all like gdb and other projects already support so they can do a single binary build for different targets * easier build tests for us as we don't need 30+ separate build dirs when we want to change common sim code, just a single build dir * reduction in duplication & effort so we don't have to maintain all the various ad-hoc implementations of the same (functional) models * easier for end users as they only need one `run` and not multiple ones to support every target * reduction of hand curated build files -- automake's Makefile.am is much smaller than our hand-written Makefile.in's today but i can't do this all at once, and tbh i don't have an exact road map written out. i have these high level goals in mind and that's what i'm meandering towards piece by piece. i try to always move forward, but at worse, only move a bit laterally. > I don't agree that this is the right intermediate state to move to. > Sure, sometimes things have to get worse before they can get better, > but this feels like an even stronger argument for putting all of the > "worse" into a single central location, rather than replicating it all > over the place. in my final vision, neither of these things would exist which is why i'm not super enthused about moving around the centralized logic. i would still want to throw it away eventually (given my end states above), so doing it this way in the meantime seems fine to me. the code is frozen either way until it's deleted. > Given you clearly have more time for sim/ right now I think you should > just commit this and move on, I suspect we're never going to agree on > this one, and as its just an opinion thing I don't see the point in > arguing it any further. hopefully the follow up improvements make it easier to live with some of this tech debt in the interim. > If this ever causes problems in the future we just revisit this > conversation at that point :) sure, life is fluid, and we should always adapt as makes sense -mike