> 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
th
> 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 wil
> 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 correspondi
>> 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 i
> 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
tar
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
>
>> 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 a
> 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.
Woul
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/softw
>> 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://w
>> 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 t
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
>> 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?
Ex
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
> impl
>>> 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 expla
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
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) '$<' > $@
>
>
> 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
> 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
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
20 matches
Mail list logo
