I can see the attraction in a build system based on a proper full featured programming language but I've never been tempted to try gradle because I believe the approach has a fundamental flaw. I.e. that it's impossible for IDEs to reliably extract useful project structure from the build description.
Even as a 25 year vi/vim user, I've succumbed to depending on IDEs more and more and I believe that any proposed build system has to easily support deep/rich integration with IDEs. This is theoretically impossible if the build system is effectively a general Turing-complete programming language. At best you will be able to provide brittle integration or else the IDE will have to dumbly treat the entire build process as a black box.
The integration with IDEA and Eclipse for Gradle is actually quite good, the only downside is that it's "one-way". That is to say that you can't use the IDE's GUI to configure your build.
I know that Buildship, the Eclipse plugin that integrates Gradle, is actually worked on pretty heavily by Gradle contributors. I don't know about IDEA but that's the IDE that I use for Java development and the Gradle integration is very, very good.
I think that's a fundamental flaw of IDE's, they don't integrate with your development environment ;)
Something I just thought of but have yet to try, could we have a build script generate the project structure that an IDE can use and get the best of both worlds? Looking through my VS project files, 50% of it is stuff the make file would be doing, the other 50% is just a list of files and dependencies.
So let's say we generated these project files from a makefile, the IDE could still treat the build process as a black box but as part of executing that black box it gets all the information it needs for intellisense and debugging.
Both Maven and Gradle have plugins that will generate Eclipse and IntelliJ project files.
But also, both Maven and Gradle work by first building up a model of what the build will look like, then executing it. Gradle is complicated by the fact that it's much easier to run custom code that modifies the build during the build (which is why I don't like it so much), but IDEs can still inspect the build model to work out what's going on.
> Both Maven and Gradle have plugins that will generate Eclipse and IntelliJ project files.
So does this work as I suggested? Can you do whatever you want in you're build script and output something usable for eclipse?
> But also, both Maven and Gradle work by first building up a model of what the build will look like, then executing it
Isn't that pretty much what make has always done? You define outputs and what dependencies are needed for those outputs and make will work out the path to get there.
Make works on a files in -> one file out basis, and the IDE has no visibility of any other side-effects. That works for build systems with that property, but some of the interesting bits of builds touch multiple files. It's also why I like Make and Maven and don't think Bash and Ant make suitable build tools.
Maven and Gradle plugins also have the advantage that the IDE can be taught to understand what they do -- a Makefile can run a compiler, but the IDE can decide to use incremental compilation and update a debug target on-the-fly, as it can see what the project build is doing and replicate the results.
On the subject of generating project files, pretty much everyone I know prefers to use the IDE's tooling for importing build files rather than the build tool's tooling for generating IDE files. And that's probably a self-reinforcing behaviour as far as tooling quality goes.
I think it's not correct to say that Turing-completeness somehow prevents extracting project structure.
If a build tool can extract that information, why IDE could not do that? In fact this is how Gradle projects are imported
into Intellij and Eclipse: Gradle builds project model by running Groovy or Kotlin scripts, and then IDEs are working with declarative model.
The real problem is working with scripts themselves: changing them automatically (applying refactorings), providing good completion, navigation, etc. The dynamic nature of Groovy makes it much harder for IDEs to provide good tooling, but even with statically typed Kotlin it is hard because Gradle APIs are very dynamic in nature (lots of string typed APIs).
That does not mean that Turing-completeness prevents good tooling completely, it just requires more efforts and has some limits depending on a build tool`s software model.
To answer your question as to why an IDE can't do it, the reason is that in order to do it you need to solve the halting problem.
Of course, the IDE can do it if you limit yourself to a subset that is not fully Turing complete, which is what IDEA does today.
The issue a lot of people have with Gradle is that this subset is not well defined, and it's very easy to do something that works but will get the tools to have problems, and debugging such issues is not particularly entertaining.
IDE does not try to analyze Gradle scripts directly, it works with declarative model that is created by executing Gradle scripts.
Gradle works in two stages:
1. Configuration: scripts execute and produce software model (DAG of tasks essentially).
2. Execution of necessary tasks in the graph.
IDE cannot get the graph by analyzing scripts, but it does not need to: instead it can ask Gradle for the model. The model itself has nothing to do with Turing completeness.
You're not wrong about the halting problem, but the reality is that most people do simple things that the IDE can extract a lot of information about. I.e. it doesn't have to understand a function to make the function fireable from a GUI button, and that is still actually quite useful.
Even as a 25 year vi/vim user, I've succumbed to depending on IDEs more and more and I believe that any proposed build system has to easily support deep/rich integration with IDEs. This is theoretically impossible if the build system is effectively a general Turing-complete programming language. At best you will be able to provide brittle integration or else the IDE will have to dumbly treat the entire build process as a black box.