Re: Checking application of dependencies from make rules without recipes
> I can only assume you are referring to this pattern rule: > >> %.cmo: %.ml %.cmi >> $(o_compilation) '$<' > $@ > > and you're saying that if the .cmi file cannot be created, that make > should not consider this an error. I became also curious on how the clarification will evolve for the request “Checking search retries for implicit make rules”. https://savannah.gnu.org/bugs/?51311 I began to reconsider my software development approach once more after the provided feedback. > It is generally not possible to represent this behavior in makefile syntax. Will further software extensions become relevant here? > The best you can do is remove the %.cmi from the pattern rule and > declare explicit prerequisite rules for those targets that you'd like to > have a .cmi file prerequisite. I tried to increase the relevance for compiled interface descriptions there. Yesterday I published changes for my intermediate development results. https://github.com/elfring/Coccinelle-20160205/commit/13fd24aff54fd86ded5a3093f927f0fed53d1f99 I started to use static pattern rules at another place. This change triggers a need to clarify the following situation. elfring@Sonne:~/Projekte/Coccinelle/20160205/commons> LANG=C make --no-builtin-rules V=1 Makefile:215: warning: overriding recipe for target 'commands.cmo' /home/elfring/Projekte/Coccinelle/20160205/common_rules.make:9: warning: ignoring old recipe for target 'commands.cmo' Makefile:218: warning: overriding recipe for target 'commands.cmx' /home/elfring/Projekte/Coccinelle/20160205/common_rules.make:12: warning: ignoring old recipe for target 'commands.cmx' make: *** No rule to make target 'commands.cmi', needed by 'commands.cmo'. Stop. 1. This error message is appropriate at the moment while it indicates related improvement opportunities. The mentioned OCaml module “commands” should be compilable without a cmi file so far. https://lists.gnu.org/archive/html/bug-make/2017-06/msg00092.html I specified therefore a corresponding make rule pair. https://github.com/elfring/Coccinelle-20160205/blob/9597598779f3604272621f6d42ead79eaafad2a8/commons/Makefile#L214 I hoped then that the build process would still succeed because I tried to lift the dependency on a special file type. Now it seems that my expectations do not fit to the current software behaviour again. Can this approach work ever in such a design direction? 2. The shown warnings will be displayed so often that I would prefer to suppress them occasionally. Is it possible to deactivate them for such cases? Regards, Markus ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
> Your claim was that either explicit rules should come before implicit rules > or vice versa. You are more free with your choices for placement of explicit rules in make scripts (because you can not and will therefore not cancel them). You should be careful then which of your explicit rules will be configured for the use as the default make rule. This distinction has got important consequences on how the different make rule types can and should be ordered relative to each other. > > I still find that to be one of your clearer sentences, even if it left us > wondering > what these important consequences are. Bigger freedom for positioning of explicit make rules. Have you got any preferences there? > Still, if all you were saying was that implicit rule ordering can be > important, > then I think we can happily close this thread. The clarification for the mentioned distinction might be finished in principle for now. But I guess that the discussion will be continued around the handling of “optional” input files (and their effect on the usage of static pattern rules and suffix rules). Regards, Markus ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
> I don't think that's relevant: a graph's topology isn't dependent > on the order in which its arcs are enumerated. I have tried to stress the construction sequence. > When you submit a test case that demonstrates a bug, I stumbled on two special cases depending on your view of the corresponding software situation. I am unsure if any more evolution will happen there. > then I'm sure someone will look at it. Would you like to take another look at a detail from my clarification request on the topic “Checking file generation for a test script”? https://lists.gnu.org/archive/html/bug-make/2017-06/msg00126.html > Expressions calculating prerequisites are a notable case, causing "variables > before rules" > to be one guideline for writing makefiles. Thanks for your information. > You claimed that the inability to cancel an explicit rule meant something > important I got an acknowledgement that the handling of explicit rules is generally different in comparison to implicit rules in specific cases. > about whether explicit rules or implicit rules should come first. > Paul prompted you to explain what that was, but you haven't. I thought that I have tried this. Now again the documented detail for an ordering constraint: Implicit make rules can be cancelled. So it is expected that something did exist to be switched off on concrete demand. Regards, Markus ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
RE: Checking application of dependencies from make rules without recipes
>> I don't see why it makes a difference in how rule types should be ordered > A dependency graph is constructed by make scripts. I don't think that's relevant: a graph's topology isn't dependent on the order in which its arcs are enumerated. >> Only if an explicit rule does not exist will an implicit rule search >> be performed. > I got the impression that this general handling might need another look > for one of my test cases. When you submit a test case that demonstrates a bug, then I'm sure someone will look at it. >> Makefiles are not like the shell or other interpreted languages where >> commands are executed as they are parsed. > They correspond to a special category of programming languages. > I find that there are also functions supported which are > immediately executed. Expressions in some contexts are evaluated as make goes along, yes, as demonstrated by: martind@swiftboat:~/tmp/elfring-2017-06-21$ cat > Makefile badger: $(error stop here) wombat: martind@swiftboat:~/tmp/elfring-2017-06-21$ make -p 2>&1 | grep wombat martind@swiftboat:~/tmp/elfring-2017-06-21$ make -p 2>&1 | grep badger .DEFAULT_GOAL := badger badger: martind@swiftboat:~/tmp/elfring-2017-06-21$ Expressions calculating prerequisites are a notable case, causing "variables before rules" to be one guideline for writing makefiles. Those expressions aren't the "commands" of which Paul was speaking, which are in "recipes", part of "rules". No-one claimed that makefiles were completely insensitive to order. You claimed that the inability to cancel an explicit rule meant something important about whether explicit rules or implicit rules should come first. Paul prompted you to explain what that was, but you haven't. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
> I don't see why it makes a difference in how rule types should be ordered A dependency graph is constructed by make scripts. > (I assume that by "ordered" you mean which rules are defined > first in the makefile). Yes. The possibility is supported to cancel implicit rules (which refer to targets that contain the placeholder “%”) on demand during a specific construction sequence. > Only if an explicit rule does not exist will an implicit rule search > be performed. I got the impression that this general handling might need another look for one of my test cases. > Makefiles are not like the shell or other interpreted languages where > commands are executed as they are parsed. They correspond to a special category of programming languages. I find that there are also functions supported which are immediately executed. Regards, Markus ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
On Tue, 2017-06-20 at 14:19 +0200, SF Markus Elfring wrote: > > This applies only to implicit rules, not explicit rules. > > > Can an explicit make rule also be cancelled anyhow? > > No. > > Thanks for this clarification. > > This distinction has got important consequences on how the different > make rule types can and should be ordered relative to each other. I don't see why it makes a difference in how rule types should be ordered (I assume that by "ordered" you mean which rules are defined first in the makefile). Regardless of the order in which rules appear, an explicit rule is always used to build a target if it exists. Only if an explicit rule does not exist will an implicit rule search be performed. This is true regardless of whether the explicit rule comes before or after the implicit rule when parsing the makefile. Remember that make parses everything in all the makefiles first, constructing a set of internal data structures representing all the rules defined in all the makefiles and all of their explicit relationships, _before_ it tries to build any target. So by the time make is ready to build its first target, it already knows everything defined anywhere in the makefile. Makefiles are not like the shell or other interpreted languages where commands are executed as they are parsed. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
>> 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? How do you think about the following approach to determine which source files can be tried to compile even when interface descriptions are (temporarily or intentionally) not available? source_dir::=$(abs_top_srcdir)/$(TARGET)/ ml_sources::=$(addprefix $(source_dir),$(SRC)) mli_sources::=$(wildcard $(source_dir)*.mli) modules_without_mli::=$(filter-out $(basename $(mli_sources)),$(basename $(ml_sources))) $(info modules_without_mli) $(info $(sort $(modules_without_mli))) $(modules_without_mli): %.cmo: %.ml $$(OCAMLC_CMD) -c $$< Unfortunately, corresponding messages seem to indicate that my knowledge and understanding is still incomplete for the application of static pattern rules. elfring@Sonne:~/Projekte/Coccinelle/20160205/parsing_c> LANG=C make --no-builtin-rules V=1 modules_without_mli /home/elfring/Projekte/Coccinelle/20160205/parsing_c/ast_c … … Makefile:145: target '/home/elfring/Projekte/Coccinelle/20160205/parsing_c/ast_c' doesn't match the target pattern … Makefile:149: warning: overriding recipe for target '/home/elfring/Projekte/Coccinelle/20160205/parsing_c/token_c' Makefile:146: warning: ignoring old recipe for target '/home/elfring/Projekte/Coccinelle/20160205/parsing_c/token_c' … Regards, Markus ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
> This applies only to implicit rules, not explicit rules. > >> Can an explicit make rule also be cancelled anyhow? > > No. Thanks for this clarification. This distinction has got important consequences on how the different make rule types can and should be ordered relative to each other. Would you like to point any further details out for the combination (or distribution) of make rules with the same targets? Regards, Markus ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
On Tue, 2017-06-20 at 08:28 +0200, SF Markus Elfring wrote: > The wording “… override a built-in implicit rule (or one you have > defined yourself) …”might need another clarification. Does the > distinction with explicit make rules result in special consequences > here? > https://www.gnu.org/software/make/manual/html_node/Makefile-Contents.html#index-explicit-rule_002c-definition-of The phrase "or one you have defined yourself" modifies the previous "implicit rule", so it means "or an implicit rule you have defined yourself". This applies only to implicit rules, not explicit rules. > Can an explicit make rule also be cancelled anyhow? No. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
>> Would you like to add any more advice to this aspect? > > Only if you have a specific question. I have got another software development concern. The section “Canceling implicit rules” of the documentation mentions something about the omission of recipes (or do they become “empty”?). https://www.gnu.org/software/make/manual/html_node/Canceling-Rules.html The wording “… override a built-in implicit rule (or one you have defined yourself) …” might need another clarification. Does the distinction with explicit make rules result in special consequences here? https://www.gnu.org/software/make/manual/html_node/Makefile-Contents.html#index-explicit-rule_002c-definition-of Can an explicit make rule also be cancelled anyhow? Regards, Markus ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
>> 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
Re: Checking application of dependencies from make rules without recipes
On Sun, 2017-06-18 at 22:55 +0200, SF Markus Elfring wrote: > > > It seems then that the original make scripts could treat more > > > interface descriptions as optional somehow. > > > > Without know what your original makefiles said I can't comment on that. > > 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. 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. > > > Would you like to add any more advice to this aspect? > > > > Only if you have a specific question. > > I indicated further clarification opportunities already. The above was the only question (sentence ending in a question mark) in your email. If you have other specific questions please feel free to ask them. I didn't recognize any other requests for clarification among your comments. > > I don't know what else to say. > > 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? I can only assume you are referring to this pattern rule: > %.cmo: %.ml %.cmi > $(o_compilation) '$<' > $@ and you're saying that if the .cmi file cannot be created, that make should not consider this an error. It is generally not possible to represent this behavior in makefile syntax. The best you can do is remove the %.cmi from the pattern rule and declare explicit prerequisite rules for those targets that you'd like to have a .cmi file prerequisite. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
>> It seems then that the original make scripts could treat more >> interface descriptions as optional somehow. > > Without know what your original makefiles said I can't comment on that. Does such a feedback indicate that would like to look also into the corresponding development repository? Example: https://github.com/coccinelle/coccinelle/blob/07d5a85c2234521238820f7bf3b0ec304839c414/parsing_c/Makefile#L1 >> Would you like to add any more advice to this aspect? > > Only if you have a specific question. I indicated further clarification opportunities already. > I've stated the algorithm make is using; This description is generally fine. > I don't know what else to say. How much can make scripts help to manage (optional) programming interface descriptions? > Certainly the more files you have the more output is generated. I guess that this fact can grow to scalability problem. > So it shouldn't be a problem to search the output for the target that is > not being built correctly then examine the steps make follows to try to > build it. It's the same set of steps whether it's the only target in > the makefile, or one of a thousand targets in the makefile. I imagine that there are related challenges and software development tools to consider for the safer handling of dependency outlines. Regards, Markus ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
On Sun, 2017-06-18 at 21:10 +0200, SF Markus Elfring wrote: > > make will see if it can be created by using your first pattern rule; > > that means it needs a file ast_c.mli. > > This could be appropriate eventually. > > I adjusted some make scripts in this software area because of special > implementation details (or open issues). My adjustments are still > incomplete in a few subdirectories. > > It seems then that the original make scripts could treat more > interface descriptions as optional somehow. Without know what your original makefiles said I can't comment on that. A rule like this: > %.cmi: %.mli > $(i_compilation) '$<' > $@ will only be used by make to create a file "ast_c.cmi" if the file "ast_c.mli" either already exists, or make can deduce how to create it using other rules. If "ast_c.mli" doesn't exist and make can't determine how to create it, then make will consider that pattern rule as not matching and will ignore it (for that target) and try to find another one. If this pattern rule is the only way to get the "ast_c.cmi" file, then targets that depend on that file will not be able to be created either. > Would you like to add any more advice to this aspect? Only if you have a specific question. I've stated the algorithm make is using; I don't know what else to say. > > and see which file is not able to be built. > > It seems that I have got still difficulties to extract desired > information from such a display. I guess that a bigger source file > number influences my view of the discussed software development > situation in significant ways. Certainly the more files you have the more output is generated. However, make works one target file at a time and follows the same process for each one, regardless of how many other targets there are. So it shouldn't be a problem to search the output for the target that is not being built correctly then examine the steps make follows to try to build it. It's the same set of steps whether it's the only target in the makefile, or one of a thousand targets in the makefile. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
>>> LANG=C make --no-builtin-rules -f parsing-rule-check1.make >> make: *** No rule to make target 'ast_c.cmo', needed by 'parsing_c.cma'. >> Stop. > > I feel like this is the same question you've already asked, > and Philip already answered, before. An other area was eventually easier to explain. > That means ast_c.cmo doesn't exist, This description is correct at the moment. > and make can't come up with a way to build it. I have got understanding difficulties for the mentioned software behaviour. > In order to build ast_c.cmo, make could create it (based on your second > pattern rule) if it can find a way to create ast_c.ml This one should be treated as an ordinary source file (for the programming language “OCaml”) and it is usable. > AND ast_c.cmi. An “i_compilation” should usually be performed for this file. > At least one of these files doesn't exist, so it can't just use this rule. I would expect that the first pattern rule should trigger the desired compilation for interface descriptions. > If it's the ast_c.ml file that doesn't exist, This file is available. > make gives up immediately since it doesn't know any way to create that file. This reaction would be fine for an ordinary source file. > If it's the ast_c.cmi file that doesn't exist, Such a file was not generated so far. > make will see if it can be created by using your first pattern rule; > that means it needs a file ast_c.mli. This could be appropriate eventually. I adjusted some make scripts in this software area because of special implementation details (or open issues). My adjustments are still incomplete in a few subdirectories. It seems then that the original make scripts could treat more interface descriptions as optional somehow. Would you like to add any more advice to this aspect? > If that file doesn't exist This is the case at the moment. I am unsure on how this status will evolve at such a place. > and make doesn't know how to build it, so make gives up, and says it > can't build ast_c.cmo because there are no valid rules that would build it. This conclusion can be reasonable to some degree. > To know which of these situations is the case you can either look at the > contents of your directory, or run make with the "-d" option I starred at these debug data already for a while. > and see which file is not able to be built. It seems that I have got still difficulties to extract desired information from such a display. I guess that a bigger source file number influences my view of the discussed software development situation in significant ways. I am curious if an other representation could make the clarification of failed dependencies a bit easier (especially for remarkable folder sizes). Regards, Markus ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
On Sun, 18 Jun 2017 19:45:34 +0200 SF Markus Elfring wrote: > A rough approximation for further discussion: > > i_compilation?=echo > o_compilation?=echo > a_generation?=$(o_compilation) 'Checked modules: ' > > parsing_c.cma: ast_c.cmo token_annot.cmo > $(a_generation) '$<' > $@ > > %.cmi: %.mli > $(i_compilation) '$<' > $@ > > %.cmo: %.ml %.cmi > $(o_compilation) '$<' > $@ > > includes.cmi: ast_c.cmo > > > elfring@Sonne:~/Projekte/Coccinelle/20160205/parsing_c> LANG=C make > --no-builtin-rules -f parsing-rule-check1.make make: *** No rule to make > target 'ast_c.cmo', needed by 'parsing_c.cma'. Stop. > > > How do you think about such a test result? I think that the test shows that even though you have a pattern rule that could be applied to build ast_c.cmo that rule fails because ast_c.ml and/or (ast_c.cmi or ast_c.mli) is missing. But that is only my guess. The true cause could be found by running make -d. I also think this might not be the right place to ask for support on how to write Makefiles. This list is more intended to report found bugs in make or suggest improvements. regards Henrik ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
On Sun, 2017-06-18 at 19:45 +0200, SF Markus Elfring wrote: > i_compilation?=echo > o_compilation?=echo > a_generation?=$(o_compilation) 'Checked modules: ' > > parsing_c.cma: ast_c.cmo token_annot.cmo > $(a_generation) '$<' > $@ > > %.cmi: %.mli > $(i_compilation) '$<' > $@ > > %.cmo: %.ml %.cmi > $(o_compilation) '$<' > $@ > > includes.cmi: ast_c.cmo > > > > LANG=C make --no-builtin-rules -f parsing-rule-check1.make > make: *** No rule to make target 'ast_c.cmo', needed by 'parsing_c.cma'. > Stop. I feel like this is the same question you've already asked, and Philip already answered, before. That means ast_c.cmo doesn't exist, and make can't come up with a way to build it. If you showed a listing of the files that exist in the directory then we could tell you precisely what make is doing. In order to build ast_c.cmo, make could create it (based on your second pattern rule) if it can find a way to create ast_c.ml AND ast_c.cmi. At least one of these files doesn't exist, so it can't just use this rule. If it's the ast_c.ml file that doesn't exist, make gives up immediately since it doesn't know any way to create that file. If it's the ast_c.cmi file that doesn't exist, make will see if it can be created by using your first pattern rule; that means it needs a file ast_c.mli. If that file doesn't exist and make doesn't know how to build it, so make gives up, and says it can't build ast_c.cmo because there are no valid rules that would build it. To know which of these situations is the case you can either look at the contents of your directory, or run make with the "-d" option and see which file is not able to be built. If you'd like slightly less verbose (but still pretty verbose) output you can use the --debug=i option to show only implicit rule search information. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
> Could you provide examples of the Makefiles rules you tried? A rough approximation for further discussion: i_compilation?=echo o_compilation?=echo a_generation?=$(o_compilation) 'Checked modules: ' parsing_c.cma: ast_c.cmo token_annot.cmo $(a_generation) '$<' > $@ %.cmi: %.mli $(i_compilation) '$<' > $@ %.cmo: %.ml %.cmi $(o_compilation) '$<' > $@ includes.cmi: ast_c.cmo elfring@Sonne:~/Projekte/Coccinelle/20160205/parsing_c> LANG=C make --no-builtin-rules -f parsing-rule-check1.make make: *** No rule to make target 'ast_c.cmo', needed by 'parsing_c.cma'. Stop. How do you think about such a test result? See also the discussion “Replacing suffix rules in make scripts?” for relevant background information: https://systeme.lip6.fr/pipermail/cocci/2017-June/004181.html Regards, Markus ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
> Could you provide examples of the Makefiles rules you tried? It depends on the detail level you prefer and my tendency to increase corresponding efforts only incrementally. > It's very difficult to provide feedback without complete information. Would you like to add any advice to a discussion around a topic like “Replacing suffix rules in make scripts?”? https://systeme.lip6.fr/pipermail/cocci/2017-June/004181.html > Does ocamldep generate output suitable for inclusion by make? It is expected that this tool “Dependency generator for OCaml” provides appropriate dependency specifications. Regards, Markus ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Checking application of dependencies from make rules without recipes
On Fri, 16 Jun 2017, SF Markus Elfring wrote: > I got some special software development experiences by the usage of the > program “GNU Make 4.2.1-1.7” on my openSUSE Tumbleweed system. The > functionality “Generating prerequisites automatically” is desribed in > the manual. I would like to check again how good this works at the > moment. > > I am trying also a software out where such build dependencies are > provided by the tool “ocamldep”. Unfortunately, I observe still broken > build tries because of missing files which should have been built > before. I started to “fix” this for my needs by the addition of small > make functions which construct extra rules. But it seems that such > special stuff should usually not be needed according to the > documentation. > > I would appreciate further advice for this issue. Could you provide examples of the Makefiles rules you tried? It's very difficult to provide feedback without complete information. Does ocamldep generate output suitable for inclusion by make? What rule did you use to invoke it? Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
