Continuing the discussion from C Plugin exportedHeaders - what does it do?:
Hi guys, any roadmap/news on this?
AFAIK it’s still not present in 2.8 …
Or do you know of any 3rdparty solution (e.g. gradle-frank-plugin as presented in http://gradle.org/gradle-prezi/ by @torokbala - unfortunately not public)?
Thank you for any information,
I experimented quite a bit with Ivy artifacts, and I am able to resolve transitive dependencies for arbitrary artifact names using Gradle. I guess this would work for native libraries. I posted my experiment on github.
Hi Martin,
thank you for the effort and link to your project.
IMHO, the problem is much larger than resolving any arbitrary artifact from a repository.
For native binaries, the problem is (long story short):
there is no packaging spec or a mapping of target platform, operating system (toolchaing etc.) to artifact suffix, classifier etc. (at this point I would refer to e.g. nar-maven-plugin or Gentoo CHOST specification)
if one can resolve an artifact using any custom/arbitrary mechanism it still cannot participate as native binary dependency (headers, linking etc.) - either directly (in component) nor through prebuiltLibraries)
for publishing, with changes introduced in 2.9 one cannot collect a binary/ies anywhere else than in model block. But there is no way how to refer it from outside it (see my post How to reference a task defined in model block from outside it?). The only way I came up with is to reference such a task from a sibling “assembly” project (again, an ugly hack)
I am aware of the documentation chapter 69.7. Limitations and future direction stating that:
The majority of the development to date has been focused on proving the efficacy of the approach, and building the internal rule execution engine and model graph mechanics. The user facing aspects (e.g the DSL, rule source classes) are yet to be optimized for conciseness and general usability. Likewise, many necessary configuration patterns and constructs are not yet able to be expressed via the API.
which is not only a sort of disclaimer but a true description of current state 
So if I summarize my situation:
)I must say I am frustrated a lot by working with the combination of Gradle & native binaries (but not giving up :D)
I concur with everything you said. My application is not native libraries, but it is close to it, and I figure when that is solved, my problem will be solved as well.
Regarding native dependency resolution only, it looks to me like Ivy already solved the problem with the Ivy extra attributes. What is needed is a convention.
I fell in love with the new Gradle model, I find it hard to go back to the nothingness I had before.