Re: make: should -j affect cwd?

[Aleksej Saushev <asau%inbox.ru@localhost>]

  Hello,

"James K. Lowden" <jklowden%schemamania.org@localhost> writes:

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

No. Our make has more uses than just building NetBSD. There're at least
pkgsrc (which is huge), TenDRA, and I suspect that Juniper uses it.
Even if you don't add robopkg (or whatever that fork is called) here and
other projects, pkgsrc alone is enourmous.

> 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 very make should handle any package in pkgsrc and pkgsrc-wip.
I don't see how you're going to handle it. Do you mean that pkgsrc
should install NetBSD make even on NetBSD? We cannot get pkg_install
out of base, which is much easier than fixing make.

> 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?  

This is bad approach. It doesn't improve anything, it only makes code
kludgier in order to support two make dialects at the same time.
How does it help?

I still don't see how you address immediate engineering problems in
your proposals. There're more or less well-understood problems in make.
In particular, there's no phase separation in make language, not even
between parsing and interpretation. And it isn't obvious if such
separation is possible at all. You can see a small general-purpose
textual preprocessor language trying to break out of make, but there's
no clear separation between preprocessor and interpretation phases
either, and it would be nice to have as well. (Whether this
macroprocessor can or will be used outside make is separate issue.
I'm pessimistic on it, <dholland> is optimistic.)


-- 
HE CE3OH...