bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #60297] optimize autodeps


From: Dmitry Goncharov
Subject: [bug #60297] optimize autodeps
Date: Sun, 4 Apr 2021 17:26:50 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

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:

  <https://savannah.gnu.org/bugs/?60297>

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]