[bug #60297] optimize autodeps

2021-04-04 Thread Dmitry Goncharov
Follow-up Comment #17, bug #60297 (project make):

> Just a note, in various examples you give prerequisites to the
.SECONDEXPANSION target; these are ignored.

Indeed, i was thinking about having this feature and added %.o, but should not
have.


> there's already a lot of complexity around intermediate/secondary/etc. files
:)

agree



> The first is for %.h.  However, this is not really necessary as far as I can
tell.  First, all the headers will be listed (after the $(file <%.d) is
expanded) as explicit prerequisites of the target so they won't be
intermediate files anyway.

i was thinking about whether the headers files are really intermediate in this
case. Not what the current implementation does, but are they really
intermediate? It is possible to code either way. i came to conclusion that
header files are intermediate, because make learns about them through stem
expansion in $(file <%.d). Since the %.d file, that the headers file come
from, is intermediate, header files are also intermediate.







> Second, headers are almost always source files (not built by make and so not
eligible to be removed).

agree

> The only time a source file would be removed is if the user deleted it,
which is why the %.h pattern exists: solely as a way to keep make from
complaining until the .d file can be rebuilt and the deleted header
disappears.

agree

> In the rare situations where a header is an intermediate file (built from
something else) you currently need to list it as a specific prerequisite
anyway and people seem OK with that.

There are situations where it is difficult for the user to list files (header
files or otherwise) explicitly. That's when implicit rules save us.


> The second is for %.d.  Assuming we have some variable or set of variables
that lists all the object files to be built, which almost all makefiles must
have or can have cheaply, we don't really need this one because we can force
all the %.d files to be not intermediate by mentioning them somewhere as a
prerequisite to some target.

I agree that explicitly listing all dep files eliminates a need for %.d
pattern. There are situation when it is difficult. I presented some such
situations in update 6. Obtaining this list usually comes with runtime cost of
reading the filesystem and additional code in the makefile.

> I will agree that there's something nice about being able to just mark all
%.d files as not intermediate without having to know all the .o files in a
variable like this.  But is it worth the extra complexity? 

i look at this as not "something nice". i look at .NOTINTERMEDIATE as a
missing feature in make interface.

When the user asks "i am using implicit rules, how can i ensure that files
which match a specific pattern are not intermediate?" the usual answer is "you
can work around with listing all of them explicitly". If the user can list
them explicitly, why use implicit rules?


Implementation wise there is additional code.
On the other hand, i feel, .NOTINTERMEDIATE simplifies make interface.
We can now describe make user interface as presented in update 10.
Let us repeat it here

1. make provides explicit rules.
2. make provides .INTERMEDIATE to accompany explicit rules to let the user
mark a target of choice as intermediate, when it otherwise would be not
intermediate.
3. make provides pattern rules with implicit search.
4. make provides .NOTINTERMEDIATE to accompany implicit rules to let the user
mark a pattern of choice as not intermediate, when it otherwise would be
intermediate. 


i think of .SECONDARY as of a parametrized .INTERMEDIATE, rather than a part
of this interface.
i suspect, had .NOTINTERMEDIATE existed since day 1, .SECONDARY may never have
been implemented and the code base would have been simpler.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[bug #60297] optimize autodeps

2021-04-04 Thread Paul D. Smith
Follow-up Comment #16, bug #60297 (project make):

I may be wrong about headers not being intermediate after $(file); I thought I
had tested this but I just realized I hadn't saved the last edit to my
makefile buffer.  I have to run now I'll look into this again later.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[bug #60297] optimize autodeps

2021-04-04 Thread Paul D. Smith
Follow-up Comment #15, bug #60297 (project make):

Just a note, in various examples you give prerequisites to the
.SECONDEXPANSION target; these are ignored.  .SECONDEXPANSION is either on or
off, for the entire makefile (starting with where it was defined).  It doesn't
currently support being applied only to a subset of targets, although this
could be added as a feature.

Thanks for the extra detail.  I want to preface this by just saying I don't
really have anything against the concept of a NOTINTERMEDIATE facility, I'm
just generally against adding complexity, and there's already a lot of
complexity around intermediate/secondary/etc. files :)

There are two reasons to use this new target type in your proposal.  Let us
consider them separately.

The first is for %.h.  However, this is not really necessary as far as I can
tell.  First, all the headers will be listed (after the $(file <%.d) is
expanded) as explicit prerequisites of the target so they won't be
intermediate files anyway.  Second, headers are almost always source files
(not built by make and so not eligible to be removed).  The only time a source
file would be removed is if the user deleted it, which is why the %.h pattern
exists: solely as a way to keep make from complaining until the .d file can be
rebuilt and the deleted header disappears.  In the rare situations where a
header is an intermediate file (built from something else) you currently need
to list it as a specific prerequisite anyway and people seem OK with that.

The second is for %.d.  Assuming we have some variable or set of variables
that lists all the object files to be built, which almost all makefiles must
have or can have cheaply, we don't really need this one because we can force
all the %.d files to be not intermediate by mentioning them somewhere as a
prerequisite to some target.  For example:

build-deps: $(OBJECTS:%.o=%.d)

will be sufficient.

I will agree that there's something nice about being able to just mark all %.d
files as not intermediate without having to know all the .o files in a
variable like this.  But is it worth the extra complexity?


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/