Re: Checking application of dependencies from make rules without recipes

2017-06-27 Thread SF Markus Elfring
> 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

2017-06-21 Thread SF Markus Elfring
> 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

2017-06-21 Thread SF Markus Elfring
> 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

2017-06-21 Thread Martin Dorey
>> 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

2017-06-21 Thread SF Markus Elfring
> 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

2017-06-20 Thread Paul Smith
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

2017-06-20 Thread SF Markus Elfring
>> 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

2017-06-20 Thread SF Markus Elfring
> 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

2017-06-20 Thread Paul Smith
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

2017-06-19 Thread SF Markus Elfring
>> 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

2017-06-19 Thread 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

___
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

2017-06-18 Thread Paul Smith
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

2017-06-18 Thread SF Markus Elfring
>> 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

2017-06-18 Thread Paul Smith
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

2017-06-18 Thread SF Markus Elfring
>>> 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

2017-06-18 Thread Henrik Carlqvist
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

2017-06-18 Thread Paul Smith
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

2017-06-18 Thread SF Markus Elfring
> 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

2017-06-17 Thread SF Markus Elfring
> 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

2017-06-16 Thread Philip Guenther
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