Re: make: should -j affect cwd?

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

On Tue, 17 Jan 2012 21:23:17 +0400
Aleksej Saushev <asau%inbox.ru@localhost> wrote:

> > If building NetBSD is the minimum goal (and it probably should be)
> 
> No. Our make has more uses than just building NetBSD. 

That's fine.  The existing make has a BSD license.  It's packaged.  No
one is threatening to take it private.  

People who should know say the code verges on unmaintainable.  
ISTM that the problem specification should give rise both to a simple
program and to a small library of tree-management functions.  If I'm
over simplifying, I'm happy to be corrected and go away quietly.  So
far no one's contradicted me.  

A good make is important.   Twenty years ago there was an
expectation/hope that the whole paradigm of source files and source
trees would disappear, and make with them, to be replaced by something
more integrated and intelligent.  Now, with only 88 years left in the
21st century, it seems destined to outlive us all.  We know make will
endure.  The question is whether or not we can endure it.  

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

1.  Do you agree that the existing make soure code is irredeemable?  
2.  Do you agree its behavior is irregular and idiosyncratic?  
3.  Do you think that inside make(1) is a pure acylic graph solver
struggling to be free?  

Those are reasons to start again with the benefit of experience with
version 1.  The idea is to have predictable behavior through better
code. If we can't accomplish that, we'd better not start.  (In fact,
we'd probably better take up something safe, like potato farming.)  

If you don't agree with the problem definition I wouldn't expect you to 
agree with the solution.  

> I still don't understand what it is going to be. This involves a big
> leap and forcing everyone to convert. 

No, quite the opposite.  Here's a new make just like today's make if
you pass -A (28 lines):

#include <unistd.h>
#include <err.h>
#include <string.h>

int
main(int argc, char *argv[])
{
        int i, antique = 0;
        
        for (i=1; i + antique < argc; i++) {
                if (0 == strcmp("-A", argv[i])) {
                        antique++;
                        continue;
                }
                argv[i-1] = argv[i+1+antique];
        }
        
        argc -= antique;
        
        argv[--argc] = NULL;
        
        if (antique) 
                err(execv("/usr/libexec/bsdmake", argv), NULL);
        
        return 0;
}

There may  be some style issues.  I haven't spent a lot of time with
KNF.  I left room for new code right above the return statement.  ;-)

> Big leap doesn't sound realistic alone, 

Agreed.  

> and NetBSD isn't the only user of bmake. 

I do not propose to replace bmake for all users.  Replacing it in
base would be quite enough.  

> Slowly changing bmake and obsoleting problematic
> features is much better approach.  

Actually, experience shows that's impossible, because that's where we
are now.  Every minor change to bmake breaks many builds.  Maintaining
backward compatibility would require two forks of the same code.
Agreement on even trivial changes to the grammar is immensely
difficult, witness the thread a month ago or so about testing for Y/N.  

Radical change to the grammar is *also* undesirable.  If we wanted to
re-write all our makefiles, we could use GNU make or Cmake.  Or ant.  

I'm suggesting instead we could evaluate each grammatical element,
pruning away redundancy and spurious irregularity, implementing
features as they justify themselves.  We would converge on a feature
set by examining a bounded real-world test case.  

What subset of bmake grammar is needed or beneficial?  Most of it,
I bet.  But I also bet there are some that will have few
defenders:

1.  The .OBJDIR handling has some lion traps
2.  parallel vs. "backwards compatible"
3.  :@temp@string@
4.  I'd be curious to hear theory behind using loops to solve
acylic graphs.  

> Phase separation (lack of it) is important problem in make

I'm not sure that's true, or that it matters to performance.  More
important, I would say, is that macro evaluation be scrupulously
regular, evaluated in a single pass.  (I would like to side-step the
whole issue of macros by relying on m4, but I think some globbing and
variable modifiers will be needed.)

To restate: quality through simplicity is the goal.  

I grant that two implementations is more complex than one.  As Mouse
understood, the ability to exec the old binary would be dropped when it
became unimportant.  I understand that even with sustained
effort that would take a long time.  For that reason we'd need broad
consensus on the goal.  I suggest that goal should be the hard one,
according to Hoare: so simple that there are obviously no
deficiencies.  

As I said when I broached the subject, it seems to me that the problem
make addresses is amenable to a theoretical approach.  That interests
me.  So does giving David Holland source code he won't complain
about.  ;-)  

--jkl