I'm not sure why you think any of this is in any way "simple". An IDE will do it all automatically for you - no work certainly seems simpler than the amount of work you've put in so far.

I dont think is simple - I said that it is not simple and i would need to make it much simpler

Does really IDE make this management simple (maybe yes, i dont know as Im not using ide), Does ide let me hold my modules in such kind of tree and compile it seperately and then link it globally? - which ide for example (im using mingw compiler)

Main thing here is refactoring if i just refacof base module file name or path (folder names) does rest of the thing change in automatic?

Im not using ide becouse i just prefer my old editor, some ide's editors i was trying was les suitable for my needs

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

In some projects, includes are required to be relative to the top of the hierarchy. This allows you to have a single include directory, typically with an absolute path, and simply include headers by their full path relative that location.

g++ -I%FIR_ECOSYSTEM_ROOT% foo.cc

In which foo.cc would include files in a manner like:

#include <boost/thread/thread.hpp>

#include <my/awesome/graphics/buffer.hpp>

#include <my/awesome/network/buffer.hpp>

By retaining the path information in the include directive you gain location independence and the ability to distinguish between several headers with the same filename.

It would be ok If i can get this %THIS_ECOSYSTEM_ROOT% automaticaly by build system, becouse I hust ma copy my root projestc form one place to another - If i could gain this value it would be okay - is it possible to get this "current path" in bat or make?

(though no it probably will not help me cause I would have to set it in one bat then read it another :C

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

That required the object files be built first.

I strongly suggest you try to learn something like CMake. It allows you to specify only the primary dependencies (.c or .cpp files) and the target binaries (.exe files) and the rest is magic. In your case, you would use it to generate makefiles which you would run with make in the mingw environment. You can even write a custom rule to generate to metamega header file.

can try the Cmake - also think I can build my own scripts that would build automaticaly the common header and second that will link all the .o's in the folder tree into exe - ? - though this seem maybe a bit ugly ? I dont know - writing those scripts seem easier than learning cmake.

- as tu uglines this script for scanning and automaticaly linking all the .obj into exe is ok imo, but those one for merging all the headers into one common is aestheticaly worse imo (as it produces something important which is outside of the set of the separate module folders

dont know - mayve there are also some other possibilities..