Re: make: should -j affect cwd?

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

  Hello,

Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:

>>> For every Makefile, we could decide: should the Makefile be altered,
>>> or should the new make be extended to support it?
>
>> This is [a] 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?
>
> jklowden already explained that: it supports Makefiles that depend on
> thing we don't realize the old make does and/or don't yet have in the
> new make (thus avoiding the huge pain of forcing all Makefiles we care
> about to be updated at once), while not requiring that support to exist
> in the new make's code forever.
>
> As for the rest of this mail: I'm not jklowden, so this is written from
> my understanding of the proposal.  I may have misunderstood things, so
> what I say here may not match what jklowden had/has in mind.
>
> An unstated but very important piece of this is that the legacy support
> would be a transition measure: people would be cleaning up Makefiles
> that depend on it, either fixing them to eliminate the dependency on
> the old semantics or fixing new make to support whatever it is they
> depend on.  Once no more Makefiles need legacy mode, the old make goes
> away completely.

I still don't understand what it is going to be. This involves a big leap
and forcing everyone to convert. Big leap doesn't sound realistic alone,
and NetBSD isn't the only user of bmake. Slowly changing bmake and
obsoleting problematic features is much better approach. It is more
realistic at least.

> The alternative, really, is to continue maintaining a program that's
> grown by accretion and is now full of horrors nobody understands and
> nobody wants to maintain, including delicious little surprises such as
> the way `.if $(VAR) == "string"' and `.if "string" == $(VAR)' have
> different semantics.  (Or has that one been fixed by now?)
>
>> I still don't see how you address immediate engineering problems in
>> your proposals.  [...]  In particular, there's no phase separation in
>> make language, not even between parsing and interpretation.  [...]
>
> (a) I'm not convinced this is a problem.  You even say "it isn't
> obvious if such separation is possible at all".
>
> (b) That isn't addressed because the proposal was about how to handle
> the migration, whereas that issue is an issue of what to migrate to.

Phase separation (lack of it) is important problem in make, it is what
makes make inefficient: you have to reparse source again and again
instead of working with intermediate representation, it prevents
such basic optimisations as caching preparsed files. If make can be
changed to get some phase separation (e.g. with restricted set of
features, or by minor or less minor changes in syntax or semantics),
we would be able benefit from it (at least the most frequently used
files can be adapted to be more efficient in processing). Whether this
is possible is open problem, someone has to work on it. It may happen
that more fundamental changes are needed, but this is yet to be
demonstrated.


-- 
HE CE3OH...