4 ms·

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

by flukus 9y ago

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.

andrewaylett 9y ago
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.
- flukus 9y ago
  > 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.
  - andrewaylett 9y ago
    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.

by flukus 9y ago

andrewaylett 9y ago

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.

flukus 9y ago
> 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.
- andrewaylett 9y ago
  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.