3 ms·

Honestly I don't get why auto dependencies are even needed. IMO splitting up manually managed dependency rules into multiple, manually ordered makefiles and imp

Honestly I don't get why auto dependencies are even needed. IMO splitting up manually managed dependency rules into multiple, manually ordered makefiles and importing them in a master makefile, should work just fine. It is a lot of work to switch to from a managed environment, but if you start with this from the beginning it's not a big deal adding dependencies whenever they come up. As a developer I like having a nicely formatted dependency documentation, including comments, in one place instead of having to look at what autoconf & co are spitting out.

strager 13y ago
So every time I add an import or #include, I need to update the dep graph manually? That may work for larger teams, but that would seriously hurt productivity for smaller projects. I think the main issue with approaches like yours is that there's no way to verify correctness, so it's easy to introduce bugs.
- m_mueller 13y ago
  - small projects should also lead to small dependency graphs, so I don't really get why it's bad there. - I'm just not a big fan of automating the configuration of a build system - you build/put yet another machine around a machine. As long as it works - ok, but as soon as you run into unexpected behavior it will become a huge time sink to debug. When you update the Makefile contents manually you take ownership over everything and you get a deeper understanding on how everything works together, right down to the command parameters sent to compiler and linker. If you don't want to do that I'd suggest switching to something like cmake - if it has to 'magic', at least have the behavior specified in a coherent manner.
stormbrew 13y ago
How does this lead to having dependency information in one place? It puts it in at least two. The file and the makefile. Not at all sure what autoconf has to do with anything, autodeps are a completely separate problem space.
- m_mueller 13y ago
  What I meant was one place to look for dependencies for the whole project and/or one of its modules - if it's only documented in the source I need to analyze all the source files instead. But you're right that the information is duplicated - a price I'm willing to pay here. And yes, I meant auto dependencies, not autoconf, sorry about that.

strager 13y ago

So every time I add an import or #include, I need to update the dep graph manually? That may work for larger teams, but that would seriously hurt productivity for smaller projects. I think the main issue with approaches like yours is that there's no way to verify correctness, so it's easy to introduce bugs.

m_mueller 13y ago
- small projects should also lead to small dependency graphs, so I don't really get why it's bad there. - I'm just not a big fan of automating the configuration of a build system - you build/put yet another machine around a machine. As long as it works - ok, but as soon as you run into unexpected behavior it will become a huge time sink to debug. When you update the Makefile contents manually you take ownership over everything and you get a deeper understanding on how everything works together, right down to the command parameters sent to compiler and linker. If you don't want to do that I'd suggest switching to something like cmake - if it has to 'magic', at least have the behavior specified in a coherent manner.

stormbrew 13y ago

How does this lead to having dependency information in one place? It puts it in at least two. The file and the makefile. Not at all sure what autoconf has to do with anything, autodeps are a completely separate problem space.

m_mueller 13y ago
What I meant was one place to look for dependencies for the whole project and/or one of its modules - if it's only documented in the source I need to analyze all the source files instead. But you're right that the information is duplicated - a price I'm willing to pay here. And yes, I meant auto dependencies, not autoconf, sorry about that.