Re: make: should -j affect cwd?

["James K. Lowden" <jklowden%schemamania.org@localhost>]

On Sun, 15 Jan 2012 07:10:56 +0000
David Holland <dholland-tech%netbsd.org@localhost> wrote:

> We need to
> either dump compat mode entirely, or bring the -j behavior into line
> with the way compat mode works, or sort out the code so that
> parallelism and compat mode are independent concepts. Because the guts
> of make are horribly bodgy, none of these is a trivial undertaking....
> 
> And so because there's no clear path to take, nothing happens...

My thanks, first of all, to you, Alan, and Mouse for the information I
need to solve my immediate difficulty.  

Everyone I talk to says the BSD make code is the ugliest thing not
walking on two feet.  Because fools rush in where angels fear to tread,
let me ask, Why not start from scratch?   I know: compatibility.  But we
already have compatibility in the existing make.  What we need is a
make compatible enough to be used by, say, automake, and whose code
isn't a Superfund site.  

Why do we shackle ourselves to something unmaintainable?  Is the ab
nihilo task really so hard?  Not if compatibility isn't the primary
goal. A simple project like pkgsrc/devel/xmake is under 2000 lines of
C.  

The theoretical problem interests me from a CS perspective:
partition and solve an acyclic dependency graph.  The "graph
solver" could be used for other things e.g. a spreadsheet.  I've looked
for such a thing as a C library or service, but never found one.
(Which is odd given the attention graphs have received over the years.)
Certainly there's nothing in pkgsrc or libc.  

As you say, the fundamental computing assumption has changed.  Moore's
Law continues apace, but the transistor pipeline is getting wider
instead of deeper. The appropriate default for make was and is to run
one process per processor, to use the whole machine.  Today and for the
foreseeable future that means solving the graph in parallel, with the
default number of processes equal to that of processors.  (We still have
nice(1) if need be.)  

There are lots of makes and near-makes: GNU make, imake, Cmake, dmake,
Omake, XMake, not to mention ant and the like. AFAICT none of them
produced anything akin to qsort(3) or bsearch(3) for tree
manipulation.  

Because there are quite a few others, and because GNU make
is 1500% as many lines as XMake, I infer:

1.  a simple make *is* easy
2.  it's hard to keep it simple
3.  the larger problem is macro processing, not graph-solving

Therefore the problem isn't technical but social.  There's not enough
agreement on the feature set to start, or the union of "minimal"
features looks more like a 30,000 line problem than a 2,000 line
problem.  Does that evaluation change if m4 is used for the macro
expansion?  

I'm interested to hear what others think.  make might be my favorite
utility.  ISTM it's a shame to let it ossify into decreptitude when we
have the knowledge and talent to revitalize it.  

--jkl