Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support composite builds when generating runs #871

Open
wants to merge 1 commit into
base: FG_5.0
Choose a base branch
from

Conversation

SquidDev
Copy link
Contributor

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. SquidDev/fg-composite-demo@c46e017 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.

 - Run generators will now write to the root of the composite build,
   rather than the root of the current project.

 - When in a composite build, attempt to find the full path to the
   current project.
@sciwhiz12 sciwhiz12 added the feature Adds a new feature to the codebase label Jun 22, 2022
@LexManos
Copy link
Member

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

@marchermans
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

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 SquidDev marked this pull request as ready for review September 6, 2022 08:04
@SquidDev
Copy link
Contributor Author

SquidDev commented Sep 6, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Adds a new feature to the codebase
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants