3 ms·

The problems match my experience with Gradle pretty well, and they point to a bigger issue in build systems: you usually can't easily debug the build system. Mo

by emsy 6y ago

The problems match my experience with Gradle pretty well, and they point to a bigger issue in build systems: you usually can't easily debug the build system. Most build systems try to be declarative, but can't help to have imperative parts where order of execution matters or when a certain environment variable is set. You have these kind of problems in Gradle and I experienced them in Cmake, Maven and Make as well. At some point you just want to step-debug or have the environment variables print at a certain point during the build. All I want is a build tool where I declare my build by simply calling functions (or extend with custom functions) and if there's an issue I want to be able to step through the script and check what's wrong.

cataphract 6y ago
You very much can debug Gradle. It's just like any other Java/Groovy application. You set a breakpoint in the build file or some Gradle source file and you attach a debugger. In this respect, it's probably more debug-friendly than, say Makefiles where all you can do is add some print statements or go through megabytes of debug output.
- wasyl 6y ago
  Adding to that, in IntelliJ it's as simple as running the task from the 'run Gradle task' window (not sure how it's called) with Shift pressed. All the breakpoints in the build scripts will now work. If you also use wrapper with sources (`-all` instead of `-bin` suffix in the `gradle/wrapper/gradle-wrapper.properties`) you can step into the entire Gradle source code as well
- santoshalper 6y ago
  In over 30 years of programming, I have never had to debug a makefile. I think I would just retire if I ever had to.
  - emsy 6y ago
    Sometimes builds are complex. You have several deployment paths, platforms, modules, features, signing and what not. Then the build is akin to a small program. That’s still reasonable. The problem is that all build tools that allow this make it more complex than simply writing a small script that does exactly what you need. Add to that that some dependemcies use a different build tool that you use. Adding a cmake dependency to a make project makes everything even more complex.

by emsy 6y ago

cataphract 6y ago

You very much can debug Gradle. It's just like any other Java/Groovy application. You set a breakpoint in the build file or some Gradle source file and you attach a debugger. In this respect, it's probably more debug-friendly than, say Makefiles where all you can do is add some print statements or go through megabytes of debug output.

wasyl 6y ago
Adding to that, in IntelliJ it's as simple as running the task from the 'run Gradle task' window (not sure how it's called) with Shift pressed. All the breakpoints in the build scripts will now work. If you also use wrapper with sources (`-all` instead of `-bin` suffix in the `gradle/wrapper/gradle-wrapper.properties`) you can step into the entire Gradle source code as well
santoshalper 6y ago
In over 30 years of programming, I have never had to debug a makefile. I think I would just retire if I ever had to.
- emsy 6y ago
  Sometimes builds are complex. You have several deployment paths, platforms, modules, features, signing and what not. Then the build is akin to a small program. That’s still reasonable. The problem is that all build tools that allow this make it more complex than simply writing a small script that does exactly what you need. Add to that that some dependemcies use a different build tool that you use. Adding a cmake dependency to a make project makes everything even more complex.