3 ms·
Surely maintaining a single build file for enormous code projects worked on by many different teams would cause more harm than good? The paper writes this issu
by RyanZAG 13y ago
Surely maintaining a single build file for enormous code projects worked on by many different teams would cause more harm than good?
The paper writes this issue off as 'same stuff in one or many files, same complexity', but obviously this isn't the case when multiple teams are involved who don't understand the work or requirements of other teams. The paper feels far too theoretical and is likely why nobody has taken much note and recursive makefiles are still the most used form for very large projects 10+ years after the paper.
- Nursie 13y agoYou can end up with all the build logic in a central place but with the module level makefiles basically just being a list of files and targets. The only real difference between the proposed solution and a 'normal' recursive make is really that these are written as 'include' rather than full makefiles, and dependencies better tracked. You don't end up with a single file until make parses everything. >> obviously this isn't the case when multiple teams are involved who don't understand the work or requirements of other teams. Massive projects with multiple teams probably won't want to work like this. He's mostly looking at a single product level, most likely worked on by a single team, he's concerned about speeding up their build times. AFAICT.