Re: [bug #62228] prerequisite based on input file created during processing not created, but no error

[Edward Welbourne]

Greg Minshall (30 March 2022 01:27) replied:
> thanks very much for the reply.  and, for the hints (on better use of
> make functions).

You're welcome. I do recommend reading the make info pages for the
details more often than most developers seem to - most of the tools I've
seen that claimed to be improvements on make have shown quite clearly
that the author didn't know how to use make to do better than their
fancy new tool could.

>>> something:
>>>      @touch ${NEWIN}

>> It is generally good to let make know what files a rule creates, rather
>> than creating files as a side-effect of making a phony target.

> i guess this is the key.  in my actual application, the "something" rule
> is a "git pull", which updates the file system with files about which my
> Makefile has no knowledge (other than that, e.g., they end in ".input").

Back when version control was SCCS and RCS, where one had to check out
each file explicitly by name, make could handle version control for you
(indeed, I had a whole system for RCS-managed files driven by makefiles;
I doubt I am the only one). However, with the advent of whole-tree
version control, such as CVS, a version control command could cause all
manner of change that the rule to drive them could not possibly
anticipate or describe to make.  With git this is even more the case, if
only because git makes easy some things that were hard in CVS.

> i guess the "right" solution for me is to do a sub-make at that point,
> to make the files in the pattern rules based on the then-current
> contents of the file system.

I confess I don't see how a sub-make would really help there.  I
generally do my git changes separately from invoking make - and, even
then, incremental builds sometimes require (at least) a purge of
generated dependency files, to force their recreation, since
interdependencies can all too easily have changed - indeed, whole
subdirectories may have been renamed, which is way outside what I would
expect make to cope with.  Perhaps others on this list have guidance on
that.

> again, thanks for the reply.  and, the tool!

As to the tool - I take it you mean make itself - than Paul and GNU.org
for that - I cannot claim credit ;^>

        Eddy.