Re: make: should -j affect cwd?

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

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

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

"Simple" projects don't work.

> 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

Simple make may be easy, but we don't want simple make, we want it
practical in the first place.

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

There's a lot of code that relies on make as it is. Are you going to
convert it yourself? Are you going to support conversion and writing new
code for as long as it is needed to complete conversion? This is the
impact you have to consider if you want to propose anything instead.
David's approach doesn't assume such hard revolutionary moves.


-- 
HE CE3OH...