On 9/24/14, 3:47 PM, H. S. Teoh via Digitalmars-d wrote:
I've been thinking of that too! I have in mind a hybrid between tup and
SCons, integrating the best ideas of both and discarding the bad parts.
For example, SCons is notoriously bad at scalability: the need to scan
huge directory structures of large projects when all you want is to
rebuild a tiny subdirectory, is disappointing. This part should be
replaced by Tup-style OS file change notifications.
However, Tup requires arcane shell commands to get anything done --
that's good if you're a Bash guru, but most people are not.
Well, what I see here is there's no really good build system there. So
then how can we interpret your long plea for dropping make like a bad
habit and using "a properly-done" build system with these amazing
qualities? To quote:
I wish I could inspire them as to how cool a
properly-done build system can be. Automatic parallel building, for
example. Fully-reproducible, incremental builds (never ever do `make
clean` again). Automatic build + packaging in a single command.
Incrementally *updating* packaging in a single command. Automatic
dependency discovery. And lots more. A lot of this technology actually
already exists. The problem is that still too many people think "make"
whenever they hear "build system". Make is but a poor, antiquated
caricature of what modern build systems can do. Worse is that most
people are resistant to replacing make because of inertia. (Not
realizing that by not throwing out make, they're subjecting themselves
to a lifetime of unending, unnecessary suffering.)
So should we take it that actually that system does not exist but you
want to create it?
Andrei
