Within the runDatagen task, a task expected to be able to be cached, there's the /tmp/loom-classpath<rng.long>.args within the jvmArgs field, which due to its random nature, practically invalidates the cache.
Expected Results
Gradle to be able to not need to run the datagen task after the first or second time.
Actual Results
Gradle can't not run the datagen task due to the mentioned argument above.
Possible Fix
Replace the Files.createTempFile with a custom call, creating a hash depending on the running user and the to-be file contents.
It maybe considered to then hold a write/delete lock to prevent competing Looms causing problems, letting only the last one releasing the lock to delete it, not that I expect there to be a case of this happening under normal conditions.
One thing to keep in mind is we wouldn't want to start skipping the normal run game tasks if their inputs havent changed
It is possible to tell Gradle that the task is not cacheable with Task.notCompatibleWithConfigurationCache(String), which would be applicable to the runClient and runServer tasks.
To accommodate it, the run configs should default to not compatible for the reason of "Application/Game Runner", with the datagen run defaulting to cacheable. It may be ideal to allow new run configs to be declared as cacheable if the dev needs it to be.
Within the
runDatagentask, a task expected to be able to be cached, there's the/tmp/loom-classpath<rng.long>.argswithin thejvmArgsfield, which due to its random nature, practically invalidates the cache.Expected Results
Gradle to be able to not need to run the datagen task after the first or second time.
Actual Results
Gradle can't not run the datagen task due to the mentioned argument above.
Possible Fix
Replace the
Files.createTempFilewith a custom call, creating a hash depending on the running user and the to-be file contents.It maybe considered to then hold a write/delete lock to prevent competing Looms causing problems, letting only the last one releasing the lock to delete it, not that I expect there to be a case of this happening under normal conditions.
Other
https://github.com/FabricMC/fabric-loom/blob/097fd98fc91fdbe9ec42f2304991b68bb29751e4/src/main/java/net/fabricmc/loom/task/AbstractRunTask.java#L127-L133
To accommodate it, the run configs should default to not compatible for the reason of "Application/Game Runner", with the
datagenrun defaulting to cacheable. It may be ideal to allow new run configs to be declared as cacheable if the dev needs it to be.