Re: make: should -j affect cwd?

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

On Sun, 15 Jan 2012 23:12:28 -0500 (EST)
Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

EHLO Mouse, 

> So, it sounds to me as though a first step would be to document
> exactly what we have.  Warts and all.  

I would like to agree with you, Mouse, but the existing man
page is the result of exactly that effort to date.  For exactly the
reason of complexity you allude to, the existing behavior cannot be
documented with confidence much more precisely than it is now.  

> Of course, our current make is buggy

Of course, if we successfully executed your suggestion, it would *not*
be buggy, by definition, because behavior would exactly conform to the
documentation.  ;-)

> it's far too large to be bug-free

28,509 lines of .c and .h, only a little smaller than GNU.  Some of it
very readable, just glancing over it.  Even commented!  meta.c is no
picnic, though.  

And here we simply must quote C. A. R. Hoare:  

        "There are two ways of constructing a software design: One way
is to make it so simple that there are obviously no deficiencies, and
the other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."

It would appear we took the easy way.  FSVO "we", that is.  

> Without
> either compatability (damn near bug-for-bug compatability) with an
> existing make, or an organization the size of the FSF's fanbase
> pushing it, it's not really going anywhere.

If building NetBSD is the minimum goal (and it probably should be) I
would suggest an ever-receding hack to achieve backward compatibility:
execute the old code.  The new make would have an Old Make option,
perhaps -A (for "antique") which would cause make to exec the old
binary.  

Here's a straw man:

1.  Write a make that builds ~80% of the programs in usr.bin. 
2.  Move /usr/bin/make to /usr/libexec/bsdmake. 
3.  New make becomes /usr/bin/make.
4.  Modify all non-building parts of the tree to use "make -A".  

This would give us:

1.  a make we understand and can extend
2.  bug-for-bug compatibility
3.  a path toward extinguishing the old make

For every Makefile, we could decide: should the Makefile be altered, or
should the new make be extended to support it?  

> [jklowden]
> > 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.
> 
> We have the talent.  We have the knowledge, but it exists in an
> un-codified distributed form which is difficult to do anything useful
> with.  

Acknowledged.  The first thing is to see if there's agreement on the
problem.  

Regards, 

--jkl