WARNING: '80s tech! Still in early development! ;)

It aims to have the following features, though:

• [x] Single-file drop-in build to kickstart simple C/C++ projects
• [x] Flexible and scaleable enough to allow reasonable growth without worrying about a real build sytem
• [x] Familiar config macros, with ready-to-use defaults for common setups
• [x] Basic facilities to configure external deps. (libs)
• [x] Doesn't impose any additional external deps. itself
• [x] Handle src. subdirs transparently (something NMAKE hates to do...)
• [x] Build a lib from (part of) the sources
• [x] Build executable(s), too, of course
• [ ] Basic (configurable) smoke-testing of build results
• [x] DEBUG/release build alternatives (DEBUG=1/0, default: 0)
• [x] Static/DLL CRT build alternatives (CRT=static/dll, default: static)
• [x] Separate target trees for the (incompatible) build alternatives
• [x] Cleanup tasks (either a build alternative only, or all outputs)
• [ ] Debug/release executables can be the same file (with overwrite) (may require "Auto-detect changes in the build command line")
• [ ] Header dependency auto-tracking
• [ ] (Some?) support for C++ modules
• [ ] Auto-detect changes in the build command line or in env. vars to trigger full rebuild (might be possible even without a thin runner script to capture the make command line)

(Note: the "src" and "include" dirs. in the repo are just examples/tests.)

DEV. NOTES:

• Due to NMAKE's inability to handle arbitrary subdirs flexibly in the source/target tree (namely, in inference rules), recursive dir traversal has to be delegated to shell commands (e.g. in a wrapper script, or some "driver" rule) instead.

  (While NMAKE can execute shell commands during preproc. time to gather files or subdirs recursively anywhere, the problem is that the results of those commands can't be assigned to macros. Also, !INCLUDE files could be created on-the-fly during preprocessing time, but only very simple ones, as the hostile "programming environment" of the !IF [...] directive combined with the CMD command-line it provides makes a failed Mars-mission feel like a dream holiday in comparison.)

• To avoid having to name the taget modules one by one, especially across multiple directories, the only sane way to enumerate them (with most make tools) is

  1. to assume a 1-to-1 relationship between the (relative) paths of certain source file types (i.e. the C/C++ translation units) and their corresponding targets (i.e. object files),

  2. and map those source names to their matching target names to allow compiling -- via inference rules -- implicitly, identifying them by their types and locations, not their names.

  However, due to two other inabilities of NMAKE, i.e. that a) it can't do pattern-matching for paths in inference rules, and b) it can only match wildcards on dependency lines -- which is too late for using the results as target lists in other rules (note: not even its false-hope-inducing EXIST() function can deal with wildcards) --, a recursion trick is used, as described below (with its core idea having been borrowed from https://stackoverflow.com/a/65223598/1479945). (Note: GNU make does support path patterns in inference rules, and also has macro facilities to manipulate paths with wildcards during preproc. time, and lets you set the results as macro values, all of which make processing filesystem trees practically effortless there.)

  With NMAKE, where wildcard-expansion results can only propagate from dependency lines downward to command blocks, there's one more "secret" place, however, where those wildcard-matching results can still make their way to rule definitions (as targets): the make command-line itself.

  So, we can call NMAKE again, now with the expanded target list, and just let it then apply the matching rules to build them.

  Well, almost... Because of its crippled path matching in inference rules, we also have to pass it the current dir path explicitly, so it can use that in those rules. This also means that we must process the source tree dir-by-dir, can't just grab all the sources, patsubst them to their corresponding target name pairs, and pass the whole list to a new make subprocess in one go. Alas, every dir will need a new child NMAKE process. (But at least the dir traversal itself is not recursive...)

  (Of course, with the abomination NMAKE is, even this will entail a lot of convoluted workarounds, so this is easier said than done -- but at least it can be done, somehow, eventually... What's still a long way away, though, is header autodependecy tracking. GCC is, again, way ahead of MSVC in this regard, unfortunately. I.e. the CL -showIncludes option is an insulting joke.)