search

MinecraftForge / ForgeGradle

Minecraft mod development framework used by Forge and FML for the gradle build system
GNU Lesser General Public License v2.1
508 stars 436 forks source link

Support composite builds when generating runs #871

Open SquidDev opened 2 years ago

SquidDev commented 2 years ago

This adds support for composite builds (i.e. includeBuild) to the various run generators.

As each included build is treated as a separate project, generating runs would read/write config from the non-existent <child project>/.idea rather than .idea (similarly for VSCode).

This change will walk up the entire project hierarchy to find the correct place to read/write IDE configuration. It also remaps the prepareXXX tasks to the "full" task path.

I've set up a test repository at https://github.com/SquidDev/fg-composite-demo/ which contains a mixture of projects using include and includeBuild. https://github.com/SquidDev/fg-composite-demo/commit/c46e017931677f79abfcbc41f74a276e8073dc98 is the commit which switches run generations to this branch, to allow you to see before/after.

I'm marking this as a draft for now, as it will conflict with #868.

LexManos commented 2 years ago

Without looking too deeply into this, why cant we just use root project? Instead of having to walk, and then find root?

marchermans commented 2 years ago

Because included builds are registered differently in gradle.

They are considered loosly attached to the current project and behave weirdlh when it comes to the root and their parents

SquidDev commented 2 years ago

Without looking too deeply into this, why cant we just use root project? Instead of having to walk, and then find root?

Ahh, sorry! Should have explained this a little better.

The point of includeBuild/composite builds in Gradle is to put multiple standalone projects in the same workspace. This means that each included build is an entirely separate project root - the project root of an included build is just the included build, not the project which was doing including.

Most of the time that's what you want. However, run configurations are the one thing which need to know the whole workspace they're operating in, hence jumping through the additional hoops.

LexManos commented 2 years ago

Interesting, another weirdness of gradle. All I know is we use rootProject all the time in Forge itself which uses included builds. Same for ff, and eventbus.

SquidDev commented 2 years ago

Ahh, this is terrible nomenclature on Gradle's part. When you use include(...), rootProject is the right thing (as those are treated as subprojects). However with includeBuild(...) its not (as those are treated as entirely separate projects).

The actual motivation for includeBuild (and also this PR) is to allow you to use multiple standalone projects in one Gradle build - for instance running a local clone of Forge and a mod which depends on Forge as part of the same build.

SquidDev commented 1 year ago

Marking this as ready for review as #868 is held up.