
Remake – GNU Make with comprehensible tracing and a debugger - peter_d_sherman
http://bashdb.sourceforge.net/remake/
======
IceDane
I would much rather just not use make at all than a slightly improved version.
A polished turd is still a turd. But if this is a drop in replacement, then
this could definitely be very useful.

~~~
peter_d_sherman
Calling make a "turd" is understandable, that is, to someone (like myself) who
is used to Windows and the conveniences it provides, "make" does indeed
initially look like a step backward in software development.

But, make has a larger history than might first be realized.

To start off with, "make" comes from an era of different, mostly incompatible-
at-the-binary-level Unixes. They were incompatible at the binary level because
these different Unixes ran on machines with different architectures and
different CPUs.

That means that you couldn't simply download an .EXE and expect that it work.
Nor an installer file. There was no "App Store" for these early and
architecturally incompatible machines.

Now, even though these machines were incompatible at the hardware binary
level, one of the ideas of Unix was that you could abstract away the
underlying hardware, and come up with a standard interface that would be
"more-or-less" compatible from system to system.

You've heard the expression that "Everything is a file" in Unix? Well _that
's_ the abstracted interface! (Well, that and more-or-less-standard API calls
to work with those files).

To develop software which would work on Unix, any Unix, regardless of the
underlying hardware, you would write code in C, and you would call Unix's
more-or-less standard API.

But, this required that you compile your source code for each Unix
architecture.

Since C programs typically have multiple files, it made sense to put the
compilation commands into a single "batch file" (shell script in Unix
parlance).

But, as more time went on, these "batch files"/"shell scripts" were called
upon to do more and more. That is, until they evolved into their own mini-
programming language (note that you see the same evolution in Windows
installers, e.g., NSIS).

But on Unix, because again, there were subtle differences from version to
version, these scripts would be called upon to do more and more, such as use
additional Unix tools in the compilation process, and that brought additional
problems, for example, what if one Unix's version of grep or awk or cat or
whatever -- had some feature that was missing in some other version... and
what if that feature was required to do some functionality related to the
compile/install process?

Anyway, here we see that there's one problem, the lack of binary compatibility
amoung Unixes, that creates all of these other problems related to compiling
and installing.

A polished turd? Well maybe, but one very necessary to solve those early
software development problems... But even as it stands today, there is no
standard processor/hardware for Unix/Linux, how do you get your software
written for a PC to run on a Mainframe or Supercomputer?

So is it still a turd now that the problems it was meant to address are better
understood?

I agree it's far from a perfect solution, but it's sort of "what we have" for
those problems...

~~~
nwmcsween
Can you explain how make can be improved? How make is far from perfect? If you
look at newer build systems that aren't wrappers they all follow the same sort
of rule based open end declarative language as others.

~~~
FrankHB
There are too many things to be improved, e.g. support of simple (enough)
cases w/o any scriptish code, getting away of stupid syntaxes (like
distinctions of indents with TABs vs. spaces) in makefiles, avoiding being
relied on as a command line tool in LTO builds (grep GCC source if you don't
know how MAKE is depended on), saner parallelism...

If there are not so many things to be improved, there should not have been so
many tools to replace `make`.

~~~
nwmcsween
> If there are not so many things to be improved, there should not have been
> so many tools to replace `make`.

There isn't? The actual non broken badly designed ones that don't generate a
DAG and aren't tied to a language is make, tup, ninja and redo.

