Re: make: should -j affect cwd?

[tlaronde%polynum.com@localhost]

To tech-userlevel%netbsd.org@localhost:
Cc:
Bcc: 
Subject: Re: make: should -j affect cwd?
Reply-To: 
In-Reply-To: <201201181522.KAA11858%Sparkle.Rodents-Montreal.ORG@localhost>

FWIW,

On Wed, Jan 18, 2012 at 10:22:47AM -0500, Mouse wrote:
> 
> Well...I actually think the conceptual core of make - tsort on the
> dependency graph, pruning pieces of it based on mtimes, and running
> commands - is the easy part.  I think the reason make has turned into a
> horror - to the extent it has, of course - is the ancillary facilities.
> .include, .if, .for, $(VARIABLE), $(VARIABLE:this:that:theother)....  I
> think it is no coincidence that every issue I've had with NetBSD's
> make, all the code I've written for it, has been around these latter
> facilities.  They are the least amenable to theoretical consideration,
> because the problem they are solving is difficult to codify
> theoretically - it is fundamentally a human-interface problem.

Since I had to allow compilation of big softwares (KerGIS and now 
kerTeX) on different systems, I have designed a set of basic Bourne
Shell scripts to generate Makefiles to be interpreted by a POSIX make(1)
---that is the very core of make.

The bonus of this is Makefile skeletons that are probably the smallest
that one can think of. Cross-compilation. And, what I did want from the
very beginning: a framework that removes the intermediate objects once
the target is obtained (SAVE_SPACE option), so that I do not need more
and more gigabytes to compile things (I have now the obligation to make
room to be able to compile NetBSD, while I had enough before).

This result is called RISK (Reduced Instruction Set toolKit). [So, it
the implementation is debatable, at least there is one.]

What I mean is this: instead of rewriting make, why not develop scripts
à la RISK that offer the same features that make extensions offers, plus
new features (like my SAVE_SPACE option) and encourage people to rely,
for new programs, on this framework, leaving make(1) alone?

And this will do with NetBSD proper as well as for pkgsrc.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C