>> 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 _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make