mirrors/CC-Tweaked
1
0
Fork 0
mirror of https://github.com/SquidDev-CC/CC-Tweaked synced 2025-02-03 04:39:12 +00:00
Code Issues Releases Wiki Activity
ef0af67e96
CC-Tweaked/settings.gradle.kts

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

55 lines
1.2 KiB
Plaintext
Raw Normal View History

License CC:T according to the REUSE specification (#1351) This adds SPDX license headers to all source code files, following the REUSE[1] specification. This does not include any asset files (such as generated JSON files, or textures). While REUSE does support doing so with ".license" files, for now we define these licences using the .reuse/dep5 file. [1]: https://reuse.software/
2023-03-15 21:52:13 +00:00
// SPDX-FileCopyrightText: 2022 The CC: Tweaked Developers
//
// SPDX-License-Identifier: MPL-2.0
Some "improvements" to our Gradle script - Switch to plugins { ... } imports for Forge (FG finally supports it!) - Use FG's new fg.component to clean up our Maven metadata instead. We also mark JEI as optional (using Gradle's registerFeature), which means we've no stray deps inside our POM any more.
2022-06-19 10:21:41 +00:00
pluginManagement {
Fabric lol - Add support for Fabric. This is mostly pretty simple, though does require a lot more mixins than Forge. Half this diff is due to data generators: we run them separately as some aspects (recipes mostly) are different between the loaders. - Add integration with Iris (same as our Oculus support) and REI (mostly the same as our JEI support). - Generic peripherals only support inventories (or rather InventoryStorage) right now. Supporting more of the Fabric storage API is going to be tricky due to the slotted nature of the API: maybe something to revisit after Transfer API V3 (V4?, I've lost track). Note, this does /not/ mean I will be publishing a Fabric version of CC:T. My plan is to rebase CC:R on top of this, hopefully simplifying the maintenance work on their end and making the two mods a little more consistent.
2022-11-10 19:32:13 +00:00
// Duplicated in buildSrc/build.gradle.kts
Some "improvements" to our Gradle script - Switch to plugins { ... } imports for Forge (FG finally supports it!) - Use FG's new fg.component to clean up our Maven metadata instead. We also mark JEI as optional (using Gradle's registerFeature), which means we've no stray deps inside our POM any more.
2022-06-19 10:21:41 +00:00
repositories {
Fabric lol - Add support for Fabric. This is mostly pretty simple, though does require a lot more mixins than Forge. Half this diff is due to data generators: we run them separately as some aspects (recipes mostly) are different between the loaders. - Add integration with Iris (same as our Oculus support) and REI (mostly the same as our JEI support). - Generic peripherals only support inventories (or rather InventoryStorage) right now. Supporting more of the Fabric storage API is going to be tricky due to the slotted nature of the API: maybe something to revisit after Transfer API V3 (V4?, I've lost track). Note, this does /not/ mean I will be publishing a Fabric version of CC:T. My plan is to rebase CC:R on top of this, hopefully simplifying the maintenance work on their end and making the two mods a little more consistent.
2022-11-10 19:32:13 +00:00
mavenCentral()
Some "improvements" to our Gradle script - Switch to plugins { ... } imports for Forge (FG finally supports it!) - Use FG's new fg.component to clean up our Maven metadata instead. We also mark JEI as optional (using Gradle's registerFeature), which means we've no stray deps inside our POM any more.
2022-06-19 10:21:41 +00:00
gradlePluginPortal()
Fabric lol - Add support for Fabric. This is mostly pretty simple, though does require a lot more mixins than Forge. Half this diff is due to data generators: we run them separately as some aspects (recipes mostly) are different between the loaders. - Add integration with Iris (same as our Oculus support) and REI (mostly the same as our JEI support). - Generic peripherals only support inventories (or rather InventoryStorage) right now. Supporting more of the Fabric storage API is going to be tricky due to the slotted nature of the API: maybe something to revisit after Transfer API V3 (V4?, I've lost track). Note, this does /not/ mean I will be publishing a Fabric version of CC:T. My plan is to rebase CC:R on top of this, hopefully simplifying the maintenance work on their end and making the two mods a little more consistent.
2022-11-10 19:32:13 +00:00
Clean up Javadocs a little I've no motivation for modding right now, but always got time for build system busywork! CC:T (and CC before that) has always published its API docs. However, they're not always the most helpful — they're useful if you know what you're looking for, but aren't a good getting-started guide. Part of the issue here is there's no examples, and everything is described pretty abstractly. I have occasionally tried to improve this (e.g. the peripheral docs in bdffabc08e2eb9895f966c949acc8334a2bf4475), but it's a long road. This commit adds a new example mod, which registers peripherals, an API and a turtle upgrade. While the mod itself isn't exported as part of the docs, we reference blocks of it using Java's new {@snippet} tag. - Switch the Forge project to use NeoForge's new Legacy MDG plugin. We don't *need* to do this, but it means the build logic for Forge and NeoForge is more closely aligned. - Add a new SnippetTaglet, which is a partial backport of Java 18+'s {@snippet}. - Add an example mod. This is a working multi-loader mod, complete with datagen (albeit with no good multi-loader abstractions). - Move our existing <pre>{@code ...}</pre> blocks into the example mod, replacing them with {@snippet}s. - Add a new overview page to the docs, providing some getting-started information. We had this already in the dan200.computercraft.api package docs, but it's not especially visible there.
2025-01-09 20:47:51 +00:00
maven("https://maven.neoforged.net") {
name = "NeoForge"
Fabric lol - Add support for Fabric. This is mostly pretty simple, though does require a lot more mixins than Forge. Half this diff is due to data generators: we run them separately as some aspects (recipes mostly) are different between the loaders. - Add integration with Iris (same as our Oculus support) and REI (mostly the same as our JEI support). - Generic peripherals only support inventories (or rather InventoryStorage) right now. Supporting more of the Fabric storage API is going to be tricky due to the slotted nature of the API: maybe something to revisit after Transfer API V3 (V4?, I've lost track). Note, this does /not/ mean I will be publishing a Fabric version of CC:T. My plan is to rebase CC:R on top of this, hopefully simplifying the maintenance work on their end and making the two mods a little more consistent.
2022-11-10 19:32:13 +00:00
content {
Clean up Javadocs a little I've no motivation for modding right now, but always got time for build system busywork! CC:T (and CC before that) has always published its API docs. However, they're not always the most helpful — they're useful if you know what you're looking for, but aren't a good getting-started guide. Part of the issue here is there's no examples, and everything is described pretty abstractly. I have occasionally tried to improve this (e.g. the peripheral docs in bdffabc08e2eb9895f966c949acc8334a2bf4475), but it's a long road. This commit adds a new example mod, which registers peripherals, an API and a turtle upgrade. While the mod itself isn't exported as part of the docs, we reference blocks of it using Java's new {@snippet} tag. - Switch the Forge project to use NeoForge's new Legacy MDG plugin. We don't *need* to do this, but it means the build logic for Forge and NeoForge is more closely aligned. - Add a new SnippetTaglet, which is a partial backport of Java 18+'s {@snippet}. - Add an example mod. This is a working multi-loader mod, complete with datagen (albeit with no good multi-loader abstractions). - Move our existing <pre>{@code ...}</pre> blocks into the example mod, replacing them with {@snippet}s. - Add a new overview page to the docs, providing some getting-started information. We had this already in the dan200.computercraft.api package docs, but it's not especially visible there.
2025-01-09 20:47:51 +00:00
includeGroup("net.neoforged")
Fabric lol - Add support for Fabric. This is mostly pretty simple, though does require a lot more mixins than Forge. Half this diff is due to data generators: we run them separately as some aspects (recipes mostly) are different between the loaders. - Add integration with Iris (same as our Oculus support) and REI (mostly the same as our JEI support). - Generic peripherals only support inventories (or rather InventoryStorage) right now. Supporting more of the Fabric storage API is going to be tricky due to the slotted nature of the API: maybe something to revisit after Transfer API V3 (V4?, I've lost track). Note, this does /not/ mean I will be publishing a Fabric version of CC:T. My plan is to rebase CC:R on top of this, hopefully simplifying the maintenance work on their end and making the two mods a little more consistent.
2022-11-10 19:32:13 +00:00
}
}
maven("https://maven.fabricmc.net/") {
name = "Fabric"
content {
includeGroup("fabric-loom")
includeGroup("net.fabricmc")
}
}
Switch to our own Gradle plugin for vanilla Minecraft I didn't make a new years resolution to stop writing build tooling, but maybe I should have. This replaces our use of VanillaGradle with a new project, VanillaExtract. This offers a couple of useful features for multi-loader dev, including Parchment and Unpick support, both of which we now use in CC:T.
2024-01-29 20:59:16 +00:00
Small bits of cleanup Build system: - Switch to our new maven server. This has a cleaner separation between published packages and mirrored packages, to avoid leaking those into other people's builds. - Update Gradle and Loom versions. Code: - Link to definitions instead in the breaking changes page. - Fix several unused variable warnings. Other: - Remove unsupported Minecraft versions from the issue template.
2024-06-26 17:07:56 +00:00
maven("https://maven.squiddev.cc") {
Switch to our own Gradle plugin for vanilla Minecraft I didn't make a new years resolution to stop writing build tooling, but maybe I should have. This replaces our use of VanillaGradle with a new project, VanillaExtract. This offers a couple of useful features for multi-loader dev, including Parchment and Unpick support, both of which we now use in CC:T.
2024-01-29 20:59:16 +00:00
name = "SquidDev"
content {
includeGroup("cc.tweaked.vanilla-extract")
}
}
Some "improvements" to our Gradle script - Switch to plugins { ... } imports for Forge (FG finally supports it!) - Use FG's new fg.component to clean up our Maven metadata instead. We also mark JEI as optional (using Gradle's registerFeature), which means we've no stray deps inside our POM any more.
2022-06-19 10:21:41 +00:00
}
}
Convert build script to Kotlin - Add a new Node plugin. This automatically installs npm dependencies and provides a "NpxExecToDir" to dir task. This allows us to make the doc website task dependencies a little nicer, by simply chaining tasks together, rather than doing dependsOn + `input.files(the other task output)`. - Switch over to CurseForgeGradle from CurseGradle. The latter is super clunky to use in non-Groovy languages. - Copy our Modrinth description body to our repo, and add support for syncing it. We'll still have to do CF manually I think.
2022-10-22 20:09:08 +00:00
val mcVersion: String by settings
rootProject.name = "cc-tweaked-$mcVersion"
Move the core API into a separate module It should be possible to consume the ComputerCraft's core (i.e. non-Minecraft code) in other projects, such as emulators. While this has been possible for years, it's somewhat tricky from a maintenance perspective - it's very easy to accidentally add an MC dependency somewhere! By publishing a separate "core" jar, we can better distinguish the boundaries between our Lua runtime and the Minecraft-specific code. Ideally we could have one core project (rather than separate core and core-api modules), and publish a separate "api" jar, like we do for the main mod. However, this isn't really possible to express using Maven dependencies, and so we must resort to this system. Of course, this is kinda what the Java module system is meant to solve, but unfortunately getting that working with Minecraft is infeasible.
2022-11-04 21:41:59 +00:00
include(":core-api")
Move dan200.computercraft.core into a separate module This is a very big diff in changed files, but very small in actual changes.
2022-11-04 22:31:56 +00:00
include(":core")
Move our public API into separate modules This adds two new modules: common-api and forge-api, which contain the common and Forge-specific interfaces for CC's Minecraft-specific API. We add a new PlatformHelper interface, which abstracts over some of the loader-specific functionality, such as reading registries[^1] or calling Forge-specific methods. This interface is then implemented in the main mod, and loaded via ServiceLoaders. Some other notes on this: - We now split shared and client-specific source code into separate modules. This is to make it harder to reference client code on the server, thus crashing the game. Eventually we'll split the main mod up too into separate source sets - this is, of course, a much bigger problem! - There's currently some nastiness here due to wanting to preserve binary compatibility of the API. We'll hopefully be able to remove this when 1.19.3 releases. - In order to build a separate Forge-specific API jar, we compile the common sources twice: once for the common jar and once for the Forge jar. Getting this to play nicely with IDEs is a little tricky and so we provide a cct.inlineProject(...) helper to handle everything. [^1]: We /can/ do this with vanilla's APIs, but it gives a lot of deprecation warnings. It just ends up being nicer to abstract over it.
2022-11-06 15:07:13 +00:00
include(":common-api")
Split CC:T into common and forge projects After several weeks of carefully arranging ribbons, we pull the string and end up with, ... a bit of a messy bow. There were still some things I'd missed. - Split the mod into a common (vanilla-only) project and Forge-specific project. This gives us room to add Fabric support later on. - Split the project into main/client source sets. This is not currently statically checked: we'll do that soon. - Rename block/item/tile entities to use suffixes rather than prefixes.
2022-11-09 23:58:56 +00:00
include(":common")
Fabric lol - Add support for Fabric. This is mostly pretty simple, though does require a lot more mixins than Forge. Half this diff is due to data generators: we run them separately as some aspects (recipes mostly) are different between the loaders. - Add integration with Iris (same as our Oculus support) and REI (mostly the same as our JEI support). - Generic peripherals only support inventories (or rather InventoryStorage) right now. Supporting more of the Fabric storage API is going to be tricky due to the slotted nature of the API: maybe something to revisit after Transfer API V3 (V4?, I've lost track). Note, this does /not/ mean I will be publishing a Fabric version of CC:T. My plan is to rebase CC:R on top of this, hopefully simplifying the maintenance work on their end and making the two mods a little more consistent.
2022-11-10 19:32:13 +00:00
include(":fabric-api")
include(":fabric")
Move our public API into separate modules This adds two new modules: common-api and forge-api, which contain the common and Forge-specific interfaces for CC's Minecraft-specific API. We add a new PlatformHelper interface, which abstracts over some of the loader-specific functionality, such as reading registries[^1] or calling Forge-specific methods. This interface is then implemented in the main mod, and loaded via ServiceLoaders. Some other notes on this: - We now split shared and client-specific source code into separate modules. This is to make it harder to reference client code on the server, thus crashing the game. Eventually we'll split the main mod up too into separate source sets - this is, of course, a much bigger problem! - There's currently some nastiness here due to wanting to preserve binary compatibility of the API. We'll hopefully be able to remove this when 1.19.3 releases. - In order to build a separate Forge-specific API jar, we compile the common sources twice: once for the common jar and once for the Forge jar. Getting this to play nicely with IDEs is a little tricky and so we provide a cct.inlineProject(...) helper to handle everything. [^1]: We /can/ do this with vanilla's APIs, but it gives a lot of deprecation warnings. It just ends up being nicer to abstract over it.
2022-11-06 15:07:13 +00:00
include(":forge-api")
Split CC:T into common and forge projects After several weeks of carefully arranging ribbons, we pull the string and end up with, ... a bit of a messy bow. There were still some things I'd missed. - Split the mod into a common (vanilla-only) project and Forge-specific project. This gives us room to add Fabric support later on. - Split the project into main/client source sets. This is not currently statically checked: we'll do that soon. - Rename block/item/tile entities to use suffixes rather than prefixes.
2022-11-09 23:58:56 +00:00
include(":forge")
Move our public API into separate modules This adds two new modules: common-api and forge-api, which contain the common and Forge-specific interfaces for CC's Minecraft-specific API. We add a new PlatformHelper interface, which abstracts over some of the loader-specific functionality, such as reading registries[^1] or calling Forge-specific methods. This interface is then implemented in the main mod, and loaded via ServiceLoaders. Some other notes on this: - We now split shared and client-specific source code into separate modules. This is to make it harder to reference client code on the server, thus crashing the game. Eventually we'll split the main mod up too into separate source sets - this is, of course, a much bigger problem! - There's currently some nastiness here due to wanting to preserve binary compatibility of the API. We'll hopefully be able to remove this when 1.19.3 releases. - In order to build a separate Forge-specific API jar, we compile the common sources twice: once for the common jar and once for the Forge jar. Getting this to play nicely with IDEs is a little tricky and so we provide a cct.inlineProject(...) helper to handle everything. [^1]: We /can/ do this with vanilla's APIs, but it gives a lot of deprecation warnings. It just ends up being nicer to abstract over it.
2022-11-06 15:07:13 +00:00
Make the main mod non-null by default This was actually much more work than I thought it would be. Tests pass, but I'm sure there's some regressions in here.
2022-11-09 18:58:31 +00:00
include(":lints")
Add a standalone CC:T UI Does it count as an emulator when it's official? I hope not, as this'd make it my fourth or fifth emulator at this point. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Developing/debugging CraftOS is a massive pain to do inside Minecraft, as any change to resources requires a compile+hot swap cycle (and sometimes a `/reload` in-game). As such, it's often more convenient to spin up an emulator, pointing it to load the ROM from CC:T's sources. However, this isn't practical when also making changes to the Java classes. In this case, we either need to go in-game, or build a custom version of CCEmuX. This commit offers an alternative option: we now have our own emulator, which allows us to hot swap both Lua and Java to our heart's content. Most of the code here is based on our monitor TBO renderer. We probably could share some more of this, but there's not really a good place for it - feels a bit weird just to chuck it in :core. This is *not* a general-purpose emulator. It's limited in a lot of ways (won't launch on Mac[^1], no support for multiple computers) - just stick to what's there already. [^1]: We require OpenGL 4.5 due to our use of DSA.
2023-10-28 16:55:56 +00:00
include(":standalone")
Move website source/build logic to projects/web Mostly useful as it moves some of our build logic out of the main project, as that's already pretty noisy!
2022-11-06 13:37:07 +00:00
include(":web")
Move the core API into a separate module It should be possible to consume the ComputerCraft's core (i.e. non-Minecraft code) in other projects, such as emulators. While this has been possible for years, it's somewhat tricky from a maintenance perspective - it's very easy to accidentally add an MC dependency somewhere! By publishing a separate "core" jar, we can better distinguish the boundaries between our Lua runtime and the Minecraft-specific code. Ideally we could have one core project (rather than separate core and core-api modules), and publish a separate "api" jar, like we do for the main mod. However, this isn't really possible to express using Maven dependencies, and so we must resort to this system. Of course, this is kinda what the Java module system is meant to solve, but unfortunately getting that working with Minecraft is infeasible.
2022-11-04 21:41:59 +00:00
for (project in rootProject.children) {
project.projectDir = file("projects/${project.name}")
}
Reference in New Issue Copy Permalink