Re: Checking application of dependencies from make rules without recipes

[SF Markus Elfring]

>> Does such a feedback indicate that would like to look also into the
>> corresponding development repository?
> 
> No.  At least I don't have time to review an entire development environment.

Such a choice is also fine.


> If you post the set of rules responsible for creating those files
> in the previous makefile configuration we can probably tell
> you why they behave differently, if you don't understand it.

But I find that such general feedback indicates also one of the usual
challenges for handling advanced (free) software support.

Another code example might help to achieve a bit more progress
in the desired clarification of implementation details. But it could
have been reduced too much with the consequence to look at other
(unwanted) side effects.


> I didn't recognize any other requests for clarification among your comments.

This is a pity.

I hoped somehow that your trained eyes might spot more issues
from software design patterns around the mentioned details.


>> How much can make scripts help to manage (optional) programming
>> interface descriptions?
> 
> Are you asking, how can a makefile represent a prerequisite which
> may be built, but is not required to be built and it's not an error
> if it cannot be built?

Yes.


> I can only assume you are referring to this pattern rule:
> 
>> %.cmo: %.ml %.cmi
>>         $(o_compilation) '$<' > $@


Yes.

And the original suffix rule:
https://github.com/coccinelle/coccinelle/blob/1c4474890c065711b16c7d02089a56da5a07e13a/Makefile#L512

…
.mli.cmi:
        $(OCAMLC_CMD) -c $<
…


> and you're saying that if the .cmi file cannot be created,
> that make should not consider this an error.

There are cases where this can and should happen.
I guess that this aspect affects an organisational issue.


> It is generally not possible to represent this behavior in makefile syntax.

I find this information only partly appropriate.


> The best you can do is remove the %.cmi from the pattern rule

This suggestion is only one possibility.


> and declare explicit prerequisite rules for those targets that you'd like to
> have a .cmi file prerequisite.

You referenced my approach for the conversion of a specific suffix rule
to a similar pattern rule.
The Coccinelle software can be successfully built by the published make scripts
with the effect of special limitations (and the usual remaining update 
candidates).
I am trying to adjust some details there.

But I reached a point after some tweaks where I began to stumble on
unexpected error messages because of the published dependency specifications.
I wondered about them for a while. It took also another while until the handling
of optional software data was identified as a corresponding big factor
for the discussed use case.

It is a recurring topic to clarify circumstances under which something can be
really optional (or not).

The development status is evolving as usual also for the mentioned concrete 
software.
Now I imagine that there is a need to decide on this design detail once more
in an automatic way. I am looking for further solutions besides the approaches
which I applied for a few subdirectories in one of my own development 
repositories.

How do you think about to extend information sources like the manual section
“Generating prerequisites automatically”?
https://www.gnu.org/software/make/manual/html_node/Automatic-Prerequisites.html

Regards,
Markus