aboutsummaryrefslogtreecommitdiff
path: root/sim
AgeCommit message (Collapse)AuthorFilesLines
2023-01-14sim: common: simplify hw-config.h depsMike Frysinger2-13/+9
Now that all ports (other than ppc) build in the top-level, we don't need to expand all the hw-config.h targets as a recursive dep. Each port depends on their respective header now, and the ppc port doesn't use it at all.
2023-01-14sim: build: drop AM_MAKEFLAGS settingsMike Frysinger10-185/+161
We don't have any recursive builds anymore, so we can drop this logic.
2023-01-13sim: build: delete Make-common.in logicMike Frysinger6-286/+3
Now that all (other than ppc) build in the top-level, this logic is unused, so punt it all.
2023-01-11sim: build: drop subdir Makefile.in filesMike Frysinger31-645/+0
These aren't used anymore, so punt them all.
2023-01-10sim: disable recursive make in (most) subdirsMike Frysinger4-707/+13
Now that all (other than ppc) build in the top-level, we can disable the recursive make calls to them. This speeds things up nicely.
2023-01-10sim: common: move test-hw-events to top-level buildMike Frysinger4-5/+17
This is an internal developer target that isn't normally compiled, but it can still be occasionally useful. Move it to the top-level build so we can kill off common/Make-common.in.
2023-01-10sim: move arch-specific file compilation of common/ files to top-levelMike Frysinger33-124/+137
2023-01-10sim: v850: move arch-specific file compilation to top-levelMike Frysinger2-6/+3
The arch-specific compiler flags are duplicated, but they'll be cleaned up once we move all subdir compiles to the top-level.
2023-01-10sim: sh: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: rx: move arch-specific file compilation to top-levelMike Frysinger3-9/+3
The arch-specific flags are only used by the arch-specific modules, not the common/ files, so we can delete them too.
2023-01-10sim: rl78: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: riscv: move arch-specific file compilation to top-levelMike Frysinger2-6/+3
The arch-specific compiler flags are duplicated, but they'll be cleaned up once we move all subdir compiles to the top-level.
2023-01-10sim: pru: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: or1k: move arch-specific file compilation to top-levelMike Frysinger2-6/+3
The arch-specific compiler flags are duplicated, but they'll be cleaned up once we move all subdir compiles to the top-level.
2023-01-10sim: msp430: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: moxie: move arch-specific file compilation to top-levelMike Frysinger3-9/+3
The arch-specific flags are only used by the arch-specific modules, not the common/ files, so we can delete them too.
2023-01-10sim: mn10300: move arch-specific file compilation to top-levelMike Frysinger2-6/+8
The arch-specific compiler flags are duplicated, but they'll be cleaned up once we move all subdir compiles to the top-level.
2023-01-10sim: mips: move arch-specific file compilation to top-levelMike Frysinger2-6/+10
The arch-specific compiler flags are duplicated, but they'll be cleaned up once we move all subdir compiles to the top-level.
2023-01-10sim: microblaze: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: mcore: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: m68hc11: move arch-specific file compilation to top-levelMike Frysinger2-6/+17
The arch-specific compiler flags are duplicated, but they'll be cleaned up once we move all subdir compiles to the top-level.
2023-01-10sim: m32r: move arch-specific file compilation to top-levelMike Frysinger3-9/+26
2023-01-10sim: m32c: move arch-specific file compilation to top-levelMike Frysinger3-9/+3
The arch-specific flags are only used by the arch-specific modules, not the common/ files, so we can delete them too.
2023-01-10sim: lm32: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: iq2000: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: h8300: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: ft32: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: frv: move arch-specific file compilation to top-levelMike Frysinger3-12/+9
The arch-specific flags are only used by the arch-specific modules, not the common/ files, so we can delete them too.
2023-01-10sim: example-synacor: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: erc32: move arch-specific file compilation to top-levelMike Frysinger3-16/+11
The arch-specific flags are only used by the arch-specific modules, not the common/ files, so we can delete them too.
2023-01-10sim: d10v: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: cris: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: cr16: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: bfin: move arch-specific file compilation to top-levelMike Frysinger3-8/+3
The arch-specific flags are only used by the arch-specific modules, not the common/ files, so we can delete them too.
2023-01-10sim: bpf: move arch-specific file compilation to top-levelMike Frysinger3-29/+15
We can drop the arch-specific rules from the subdir as they're no longer used.
2023-01-10sim: avr: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: arm: move arch-specific file compilation to top-levelMike Frysinger3-9/+3
The arch-specific flags are only used by the arch-specific modules, not the common/ files, so we can delete them too.
2023-01-10sim: aarch64: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: build: add basic framework for compiling arch objects in top-levelMike Frysinger4-10/+31
The code so far has been assuming that we only compile common/ objects. Now that we're ready to compile arch-specific objects, refactor some of the flags & checks a bit to support both.
2023-01-10sim: modules.c: move generation to top-levelMike Frysinger3-32/+49
Now that all arches create libsim.a from the top-level, we have full access to their inputs, and can move the actual generation from the subdir up to the top-level. This avoids recursive makes and will help simplify state passing between the two.
2023-01-10sim: build: drop common/nrun.o subdir hackMike Frysinger2-6/+0
Now that all the subdirs handle their own builds, we can drop this common rule as it's unused, and we don't want to use it anymore.
2023-01-10sim: build: drop support for creating libsim.a in subdirsMike Frysinger36-130/+3
Now that all ports have moved to creating libsim.a in the top-level, drop all the support code to create it in a subdir.
2023-01-10sim: v850: move libsim.a creation to top-levelMike Frysinger3-20/+88
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: sh: move libsim.a creation to top-levelMike Frysinger3-27/+74
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: rx: move libsim.a creation to top-levelMike Frysinger3-42/+87
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: rl78: move libsim.a creation to top-levelMike Frysinger3-41/+78
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: riscv: move libsim.a creation to top-levelMike Frysinger3-31/+83
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: pru: move libsim.a creation to top-levelMike Frysinger3-31/+80
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: or1k: move libsim.a creation to top-levelMike Frysinger3-52/+122
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: msp430: move libsim.a creation to top-levelMike Frysinger3-37/+86
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
generated by cgit v1.1 at 2025-09-19 20:28:20 +0000