Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualfir

Posted 03 June 2014 - 11:43 AM

No, make will not help you here.

 

The purpose of make is to rebuild only what has changed, and to make sure everything that depends on a change gets rebuilt (rebuild everything that's necessary, but no more).  You still need to specify dependencies somehow.  Much of the point of make is defeated if you have One Big Header that includes all other headers.

 

If you're using GNU make and the GNU compiler collection, you can use extensions that will calculate compile-time dependencies, eliminating much of the work:  that's how wrappers like the Linux kconfig system and the GNU autotools work:  you simply specifiy the translation units (generally .c or .cpp files) and the rest gets determined at build time.  Other wrappers like CMake reinvent that using their own separate codebase.  These will still give you build-time grief because of your "simplified" headers, but will be less work for you to maintain the dependencies.

 

You might also consider breaking your projects down into modules using static libraries, so each only needs to be rebuilt when the module changes and the public API is limited to the public library API:  this should simplify your link command lines and header structure in a good way, making any tight coupling manifest.

 

So, make on its own will not help you here, but using make in conjunction with wrapper tools developed over the last half century or so to solve your problems will definitely help solve your problems.  It's definitely worth your looking in to.

 

I weakly understand this, though it seem to be on point (?)

 

I was thinked - one thing i would need from compiler and linker 9at least external helper tool) is an option "to compile/link all the sources/objects from a given folder" with no need of specyfing it all by hand - it is theoreticccly physically possible but i dont know such tool

... i can also make helper scripts as i said the task is well scoped

 

- scan given folder tree find all the header files and flush its paths and names into final summaric include file

- scan given folder tree find all .o files and flush this with path into some linker bat file

 

(maybe someone would be able quickly wrote this in some language or in c as a form of exe script?)

 

 

ps, as to breaking into libraries, i was trying it, but it showed that i usually work on each parts of projest at once (both libs and middle of the games, so after division it showed to be more burdensome work than without it)

 

ps one big header is really les work when you refactor, Im not sure if you aware of this or you overcome it in some way or I am mistaken here - say you have a header namet  "zmath.h"

and use it from 17 modules, - when you want change this name

 you need to search over miriads of modules and rename it if you just have one big header you only change the name there - i was doing constatnt ferectorization of such type so it was so much slowing me so i changed to one big header - at end of the work i can put manually its constens to each module and comment out unused modules but now I need heavy refactoring able environment


#2fir

Posted 03 June 2014 - 11:34 AM

No, make will not help you here.

 

The purpose of make is to rebuild only what has changed, and to make sure everything that depends on a change gets rebuilt (rebuild everything that's necessary, but no more).  You still need to specify dependencies somehow.  Much of the point of make is defeated if you have One Big Header that includes all other headers.

 

If you're using GNU make and the GNU compiler collection, you can use extensions that will calculate compile-time dependencies, eliminating much of the work:  that's how wrappers like the Linux kconfig system and the GNU autotools work:  you simply specifiy the translation units (generally .c or .cpp files) and the rest gets determined at build time.  Other wrappers like CMake reinvent that using their own separate codebase.  These will still give you build-time grief because of your "simplified" headers, but will be less work for you to maintain the dependencies.

 

You might also consider breaking your projects down into modules using static libraries, so each only needs to be rebuilt when the module changes and the public API is limited to the public library API:  this should simplify your link command lines and header structure in a good way, making any tight coupling manifest.

 

So, make on its own will not help you here, but using make in conjunction with wrapper tools developed over the last half century or so to solve your problems will definitely help solve your problems.  It's definitely worth your looking in to.

 

I weakly understand this, though it seem to be on point (?)

 

I was thinked - one thing i would need from compiler and linker 9at least external helper tool) is an option "to compile/link all the sources/objects from a given folder" with no need of specyfing it all by hand - it is theoreticccly physically possible but i dont know such tool

... i can also make helper scripts as i said the task is well scoped

 

- scan given folder tree find all the header files and flush its paths and names into final summaric include file

- scan given folder tree find all .o files and flush this with path into some linker bat file

 

(maybe someone would be able quickly wrote this in some language or in c as a form of exe script?)

 

 

ps, as to breaking into libraries, i was trying it, but it showed that i usually work on each parts of projest at once (both libs and middle of the games, so after division it showed to be more burdensome work than without it)


#1fir

Posted 03 June 2014 - 11:30 AM

No, make will not help you here.

 

The purpose of make is to rebuild only what has changed, and to make sure everything that depends on a change gets rebuilt (rebuild everything that's necessary, but no more).  You still need to specify dependencies somehow.  Much of the point of make is defeated if you have One Big Header that includes all other headers.

 

If you're using GNU make and the GNU compiler collection, you can use extensions that will calculate compile-time dependencies, eliminating much of the work:  that's how wrappers like the Linux kconfig system and the GNU autotools work:  you simply specifiy the translation units (generally .c or .cpp files) and the rest gets determined at build time.  Other wrappers like CMake reinvent that using their own separate codebase.  These will still give you build-time grief because of your "simplified" headers, but will be less work for you to maintain the dependencies.

 

You might also consider breaking your projects down into modules using static libraries, so each only needs to be rebuilt when the module changes and the public API is limited to the public library API:  this should simplify your link command lines and header structure in a good way, making any tight coupling manifest.

 

So, make on its own will not help you here, but using make in conjunction with wrapper tools developed over the last half century or so to solve your problems will definitely help solve your problems.  It's definitely worth your looking in to.

 

I weakly understand this, though it seem to be on point (?)

 

I was thinked - one thing i would need from compiler and linker 9at least external helper tool) is an option "to compile/link all the sources/objects from a given folder" with no need of specyfing it all by hand - it is theoreticccly physically possible but i dont know such tool

... i can also make helper scripts as i said the task is well scoped

 

- scan given folder tree find all the header files and flush its paths and names into final summaric include file

- scan given folder tree find all .o files and flush this with path into some linker bat file

 

(maybe someone would be able quickly wrote this in some language or in c as a form of exe script?)


PARTNERS