Re: [PATCH] sim: testsuite: push $arch out to targets

[Mike Frysinger via Gdb-patches <gdb-patches@sourceware.org>]

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/<port>/*.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