Re: make: should -j affect cwd?

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

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

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

A good make is important, but what is its utility in your opinion?
So far the utility of bmake is mostly restricted to building packages
in pkgsrc and NetBSD. As you can see some people converted to gmake only
because they couldn't make users to use "another" non-stock make program.

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

No. There's worse code lying around.

> 2.  Do you agree its behavior is irregular and idiosyncratic?

Definitly not. In most cases make's behaviour is coherent.

> 3.  Do you think that inside make(1) is a pure acylic graph solver
> struggling to be free?

No.

What do you call a "graph solver" in the first place?

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

I still don't see how this is going to work on such project as pkgsrc.
I don't see how you address this engineering problem. In particular,
how are you going to change dialect in the middle of operation?

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

No, it is _not_ enough. We meet strong opposition when trying to change
the way pkg_install is handled in base, and that is less intrusive than
replacing one of more fundamental tools.

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

Actually, experience in pkgsrc and NetBSD clearly demonstrates that it
is possible. Most people haven't noticed radical changes in handling,
e.g., CC, CFLAGS, CPPFLAGS, and some other variables in base system.

> 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 wonder how C and C++ folks introduce radical changes into grammars and
almost noone notices.

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

OBJDIR is hardly a grammatical feature.

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

Forcing everyone to use m4 isn't realistic. Other than giving you
Turing-complete macropreprocessor m4 doesn't add any value. It is hard
to write and hard to read. You need a well-elaborate library only to
start working with it and rather rigorous rules to keep your code
maintainable.

> To restate: quality through simplicity is the goal.

You cannot make tools simpler than the problem is without imposing
the handling of excess upon programmer.


-- 
HE CE3OH...