Jump to content

  • Log In with Google      Sign In   
  • Create Account

#Actualfir

Posted 03 June 2014 - 09:42 AM

So don't reference every single source file in the root makefile? Seems to me you aren't managing your dependencies properly, why does the root makefile (or batch file or whatever) need to know that you added a file somewhere deep down in the graphics module? In most projects I've seen and worked on, each module is compiled down to a static library by a separate makefile (for instance, graphics.a, window.a, etc..), with possible dependencies between modules (for instance, graphics.a may depend on math.a) and the root makefile simply links those together with the main program to build the final executable (without any knowledge of every source file involved - just the major modules). Basically, implement the modules as libraries (even if they aren't going to be released separately - developing them separately helps a lot with modularity and is just better practice across the board).

 

 

this not helps, I was thinking about it then but abandoned it ,

here instead one summaric header with 400 inludes and same for linker you have say 4 headers with 100 includes and same 4 linker scripts 100 modules each - this is zero improvement, the real burden of carrying this 2 (or 3 if counting bats )x 400 paths  stays the same (this 3x400 project names source is a source over a source -long text of module names)


#1fir

Posted 03 June 2014 - 09:38 AM

So don't reference every single source file in the root makefile? Seems to me you aren't managing your dependencies properly, why does the root makefile (or batch file or whatever) need to know that you added a file somewhere deep down in the graphics module? In most projects I've seen and worked on, each module is compiled down to a static library by a separate makefile (for instance, graphics.a, window.a, etc..), with possible dependencies between modules (for instance, graphics.a may depend on math.a) and the root makefile simply links those together with the main program to build the final executable (without any knowledge of every source file involved - just the major modules). Basically, implement the modules as libraries (even if they aren't going to be released separately - developing them separately helps a lot with modularity and is just better practice across the board).

 

 

this not helps, I was thinking about it then but abandoned it ,

here instead one summaric header with 400 inludes and same for linker you have say 4 headers with 100 includes and same 4 linker scripts 100 modules each - this is zero improvement, the real burden of carrying this 2 (or 3 if counting bats )x 400 paths  stays the same (this 3x400 project names source is a source over a source)


PARTNERS