aboutsummaryrefslogtreecommitdiff
path: root/sim
AgeCommit message (Collapse)AuthorFilesLines
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.
2023-01-10sim: moxie: move libsim.a creation to top-levelMike Frysinger3-37/+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: mn10300: move libsim.a creation to top-levelMike Frysinger3-46/+118
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: mips: move libsim.a creation to top-levelMike Frysinger5-153/+251
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. The mips code is a little more tricky than others because, for multi-run targets, it generates the list of sources & objects on the fly in the configure script.
2023-01-10sim: microblaze: move libsim.a creation to top-levelMike Frysinger3-57/+106
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: mcore: move libsim.a creation to top-levelMike Frysinger3-57/+105
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: m68hc11: move libsim.a creation to top-levelMike Frysinger3-67/+132
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: m32r: move libsim.a creation to top-levelMike Frysinger3-77/+186
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: m32c: move libsim.a creation to top-levelMike Frysinger3-90/+136
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: lm32: move libsim.a creation to top-levelMike Frysinger3-82/+167
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: iq2000: move libsim.a creation to top-levelMike Frysinger3-87/+165
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: h8300: move libsim.a creation to top-levelMike Frysinger3-83/+132
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: ft32: move libsim.a creation to top-levelMike Frysinger3-86/+133
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: frv: move libsim.a creation to top-levelMike Frysinger3-96/+209
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: example-synacor: move libsim.a creation to top-levelMike Frysinger3-91/+143
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 2024-07-11 22:11:31 +0000