Custom Plugin Issues Honoring Dependencies


(Bill Smith) #1

We have a large multiproject build that uses the java plugin. All the dependencies are respected when running any of the traditional commands (build, jar, etc). However, we have a custom plugin that we developed that does some different processing (cpp type stuff, not the cpp plugin). When we run any of the tasks created by the plugin, it seems to ignore the dependencies as defined.

As an example, our plugin adds the following tasks: win32, win32_x64, linux_x86, linux_x64, qnx_ppc. Wen I run gradlew win32 (or any of the others) it ignores the dependencies and simply runs in alphabetical order.

I’m sure there is info I need to provide, but not sure what that would be. Does anybody have any ideas on how to get a custom plugin to honor the dependencies or what information do I need to post to help resolve this?

TIA, Bill Smith


(Peter Niederwieser) #2

Are you saying that the plugin is declaring explicit task dependencies which aren’t being respected? That’s very unlikely. A common debugging technique is to simplify the plugin (or build) until the problem no longer occurs, and then work backwards to find the cause. You might also want to play with task dependencies in a tiny build that you create for experimentation purposes.


(Bill Smith) #3

That is probably part of the problem. I’m not sure how to declare task dependencies in a generic way. I’ll only been at this for a week.


(Bill Smith) #4

I was able to finally get it to work. I’m not sure if this is the best way so I thought I’d post it here for feedback. We are in the process of migrating our custom build tool suite to gradle so we are going through a bit of a learning curve.

Basically I had to create a block for each custom task that depended on another project:

win32 {

dependsOn ‘:cppunit:win32’ }

win32_x64 {

dependsOn ‘:cppunit:win32_x64’ }


(Bill Smith) #5

As a final note, I was able to get this to work dynamically by looking at the dependency of the project and adding the above programatically during the config pass.


#6

Yep the standard task model doesn’t make it easy to handle the many different variants you want to build for C++.

This is why we’ve taken a new approach for the native binary support in Gradle. Instead of defining everything in terms of tasks, you instead configure a high-level domain model from which Gradle builds the task graph.