Gradle JavaExec task fails in IntelliJ due to missing restoreScripts dependency.

[Han-sok]

Hi RapidWright developer team,

I’ve been experimenting with building and running RapidWright directly from IntelliJ IDEA Community Edition and ran into a Gradle build/run problem. I wanted to share the details so you can confirm whether this is expected or if we need to adjust the Gradle scripts.

---

Problem Description
When I try to run DeviceBrowser or other classes via IntelliJ’s Gradle-integrated run configurations, the build fails with an error like:

A problem was found with the configuration of task ':com.xilinx.rapidwright.device.browser.DeviceBrowser.main()' (type 'JavaExec').
  - Gradle detected a problem with the following location: '/home/hansok/Projects/RapidWright_latest/RapidWright/bin'.

* Try:
> Declare task ':restoreScripts' as an input of ':com.xilinx.rapidwright.device.browser.DeviceBrowser.main()'
> Declare an explicit dependency on ':restoreScripts' from ':com.xilinx.rapidwright.device.browser.DeviceBrowser.main()' using Task#dependsOn
> Declare an explicit dependency on ':restoreScripts' from ':com.xilinx.rapidwright.device.browser.DeviceBrowser.main()' using Task#mustRunAfter

In IntelliJ’s Gradle tool window, I also notice that the :restoreScripts task appears struck through, which suggests it’s not recognized in the subproject where the DeviceBrowser JavaExec task is being created.

Running from the command line (./gradlew run) works fine. So this seems specific to how IntelliJ generates and executes synthetic JavaExec tasks.

---

Below is my environmental setups for reproducibility.

Environment

OS: Ubuntu 20.04.6 LTS
JDK: 17 Eclipse Temurin 17.0.7
Gradle Wrapper: gradle-8.14 (default from the repo)
IntelliJ IDEA: Community Edition 2025.2 (Build #IC-252.23892.409)
Build Tools -> Gradle settings:
“Use Gradle from”: Wrapper task in gradle-wrapper.properties
“Gradle JVM”: Project SDK 17
RapidWright source: latest main branch (v2025.1.1-beta-5-gf6df5495)

---

Steps to Reproduce
Clone the RapidWright repo and open it in IntelliJ IDEA CE.
Sync Gradle project.
Right-click DeviceBrowser.java → “Run DeviceBrowser.main()”.
Then I can observe the build failure with the missing restoreScripts dependency.

---

Possible Cause
The restoreScripts task is declared in the root project, but IntelliJ’s generated JavaExec tasks live in subprojects like :com.xilinx.rapidwright.device.browser. Those tasks don’t automatically know they should depend on the root’s :restoreScripts.

Gradle itself suggests adding explicit dependsOn(":restoreScripts") or declaring inputs.dir("$rootDir/bin") for the JavaExec tasks. A possible fix would be to wire all JavaExec tasks to depend on :restoreScripts, or to scope that wiring just to the device.browser subproject.

---

Suggestion
I am not sure if this is a complete fix, but I was able to resolve the issue by adding this to the build.gradle script

// --- Extra wiring to make restoreScripts visible to all JavaExec tasks ---

allprojects {
    tasks.withType(JavaExec).configureEach {
        dependsOn(":restoreScripts")
        // tell gradle we read from the generated scripts directory
        inputs.dir("$rootDir/bin")
    }
}

tasks.named("restoreScripts", Copy) {
    inputs.files("$preserveDir/rapidwright", "$preserveDir/rapidwright.bat").optional()
    outputs.dir("$rootDir/bin")
}

tasks.named("preserveBin", Copy) {
    onlyIf { file("bin/rapidwright").exists() || file("bin/rapidwright.bat").exists() }
}

[clavin-xlnx]

I'm sorry I haven't had a chance to look at this closely enough. To be honest, I am not a Gradle expert and we struggle with the build being brittle. For IDEs, we typically avoid using the Gradle build because it is usually slower than what the IDE can do with its own incremental compile offering. I would suggest trying to setup IntelliJ without using the Gradle build by simply adding all the jars to the CLASSPATH and specifying the source directories. I will have to look into this issue further soon.

[Han-sok]

Hi Chris,
Thank you for your quick response!

I understand. No problem. I mainly wanted to share this so the development team is aware that there might be an issue with using Gradle inside the IDE, in case it helps others who run into the same situation.

I’ll follow your suggestion and run my code by adding the jars to the CLASSPATH.

Best regards,
Han-sok