Re: Checking software build tries for “commands.cmo”

[SF Markus Elfring]

> I believe the point of Martin's rhetorical query is "why should make treat 
> the failure of *this* pattern rule any different than the failure of the 
> many other pattern rules that would have permitted this compilation
> to complete?"

It seems that I need to try harder for the desired clarification of
consequences when a specific source file (like an interface description file
for the programming language “OCaml”) can be occasionally treated as
an optional item in some software areas.

There will not be any make rule specified for a file type which was
intentionally left out for a specific source item.
The general challenge is to find out for how long something can be omitted
(while its use can be recommended in several situations).

Regards,
Markus

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[SF Markus Elfring]

>> I needed another moment to become really aware that this software module
>> is a bit special. It seems that it is intended that it will be compiled
>> without a corresponding interface description file (suffix “mli”).
> 
> Well, I'm totally lost.  Here's why:
> 
> You told make ".cmo files can be built from *THE COMBINATION OF* the 
> matching .cmi and .ml files, but *only* if both the files exist or can be 
> built via some other rule".  That is what this rule says:
> 
> %.cmo: %.ml %.cmi
>$(OCAMLC_CMD) -c $<

Your repetition is correct according to the development situation where
I started another try to update build scripts for an other evolving software.


> Now you're saying that commands.cmo could be built from *just* 
> commands.cmi without commands.ml!

My previous attempt was incomplete for the description of the dependency chain
“(mli ⇒ cmi ⇒)? ml ⇒ cmo”. I suggest to take another look.

The OCaml programming language is also working with interface description files.
These should be compiled when they are available at all.
But they can be optional.


I added a corresponding make rule then.

commands.cmo: commands.ml
$(OCAMLC_CMD) -c $<


This pattern corresponds to a general development challenge:
For which software modules can you depend on interface descriptions in a safe 
way?

Regards,
Markus

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[Philip Guenther]

On Thu, 15 Jun 2017, SF Markus Elfring wrote:
> > Did you tell make, then, to disable all of its default rules for 
> > creating commands.mli or, for that matter, commands.cmo, by checking 
> > them out of version control?
> 
> Not directly so far. - The source file “commands.mli” is not needed for 
> the generation of the object module “commands.cmo” in the final use 
> case.

I believe the point of Martin's rhetorical query is "why should make treat 
the failure of *this* pattern rule any different than the failure of the 
many other pattern rules that would have permitted this compilation to 
complete?"

If comands.ml,v had existed, then the make command you had invoked would 
have completed, because make would have invoked the
%:: %,v
rule and then the rule you supplied.  Alternatively, if commands.cmo,v 
have existed, then make could have used that to generate commands.cmo 
directly, so why shouldn't it say
The target “commands.cmo” could not be built because the specified
dependency “commands.cmo,v” did not exist.
?


You *looked at* the the "make -d" output and saw the long list of files 
that make considered as possible prerequisites for building command.cmo; 
if *any* of those existed then make would have been able to build the file 
and complete your request.

If you want to change the error messages that make generates, you have to 
look at that list coldly and without passion and say "is there a rule that 
improves the error output in this case?  Is that output at least as good 
for *other* makefiles?"  If the answers aren't both "yes", then you're 
suggesting a trade-off of your makefile for someone else's and have this 
consider and explain *why* their usage may be made worse to make yours 
better.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[Philip Guenther]

On Thu, 15 Jun 2017, SF Markus Elfring wrote:
> > (I would guess that most of the people on the bug-make mailing list have 
> > never worked with ocaml and therefore don't know what needs to be done to 
> > build it.)
> 
> Yesterday I realised that one source source file needed a special handling
> in the mentioned subdirectory.
> 
> 
> > The snippet of Makefile you provided didn't include any rules for 
> > building "commands.ml", so I don't understand why you expect make to 
> > build it.
> 
> The suffix “ml” denotes a source file in this use case.
> 
> I needed another moment to become really aware that this software module
> is a bit special. It seems that it is intended that it will be compiled
> without a corresponding interface description file (suffix “mli”).

Well, I'm totally lost.  Here's why:

You told make ".cmo files can be built from *THE COMBINATION OF* the 
matching .cmi and .ml files, but *only* if both the files exist or can be 
built via some other rule".  That is what this rule says:

%.cmo: %.ml %.cmi
   $(OCAMLC_CMD) -c $<

Now you're saying that commands.cmo could be built from *just* 
commands.cmi without commands.ml!  If the real rule is that .cmo files can 
be built from .cmi files (and they _sometimes_ depend on .ml files) then 
the multi-dependency rule you used should be replaced with the single 
dependency rule:

%.cmo: %.cmi
   $(OCAMLC_CMD) -c $<

...and the additional dependency of whatever.cmo on whatever.ml should be 
expressed separately...or even automatically generated like what is done 
in modern C projects.

Indeed, do .cmo files sometimes depend on _other_ .ml files, such that 
"foo.cmo" might need to be rebuilt if "bar.ml" changes?  If so, then you 
might just have too many dependencies but all too few and should be 
looking at the direction make-for-C went to solve this.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[SF Markus Elfring]

> Did you tell make, then, to disable all of its default rules for creating 
> commands.mli or,
> for that matter, commands.cmo, by checking them out of version control?

Not directly so far. - The source file “commands.mli” is not needed
for the generation of the object module “commands.cmo” in the final use case.

But I used make rule specifications for a moment to express the simple
dependency chain “mli ⇒ cmi ⇒ ml ⇒ cmo” before I became more aware about
related software constraints.

I would have found an error message like “The target “commands.cmo” could not
be built because the specified dependency “commands.mli” did not exist.”
nicer in a specific development situation.

Regards,
Markus

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Checking software build tries for “commands.cmo”

[Martin Dorey]

Sorry for my fat-fingered phoning.

>> Would you have it complain that commands.mli,v, RCS/commands.mli,v,
>> RCS/commands.mli, s.commands.mli and SCCS/s.commands.mli were missing?

> Not really in this use case.

Did you tell make, then, to disable all of its default rules for creating 
commands.mli or, for that matter, commands.cmo, by checking them out of version 
control?

> Can an error message like “The target “commands.cmo” could not be built
> because the specified dependency “commands.mli” did not exist.”
> be more appropriate instead of the message “make: Nothing to be done
> for 'commands.cmo'.”?

No, because, in general, there are many ways for make to build commands.cmo and 
not all of them involve commands.ml.  Even for the ones that do, the problem 
could have been further back, eg that SCCS/s.commands.mli was missing.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[Martin Dorey]

Would you have it complain that commands.mli,v, RCS/commands.mli,v,
RCS/commands.mli, s.commands.mli and SCCS/s.commands.mli were missing?

> Not really in this use case.

Did you tell make, then, to disable all of its default rules for creating 
commands.mli or, for that matter, commands.cmo, by checking them out of version 
control?

Can an error message like “The target “commands.cmo” could not be built
because the specified dependency “commands.mli” did not exist.”
be more appropriate instead of the message “make: Nothing to be done
for 'commands.cmo'.”?

On Jun 14, 2017, at 23:12, SF Markus Elfring 
> wrote:

I have noticed a moment ago that an interface description file was missing
somehow for the OCaml source file in this compilation attempt.
...
I wonder then that the make tool did not give me a direct clue for a failed
software dependency as I am used to in other cases.
Would you have it complain that commands.mli,v, RCS/commands.mli,v,
RCS/commands.mli, s.commands.mli and SCCS/s.commands.mli were missing?

Not really in this use case.


The existence of any of those would have let make build commands.mli, hence 
commands.cmo.

This interface description file could also be generated by a command variant
of the OCaml compiler. But it seems that it is finally not needed for
the build scripts which I am trying to update.


Can you come up with a specification for finding which of the possible
missing dependencies is the one that you actually care about?

Can an error message like “The target “commands.cmo” could not be built
because the specified dependency “commands.mli” did not exist.”
be more appropriate instead of the message “make: Nothing to be done
for 'commands.cmo'.”?

Regards,
Markus
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[Martin Dorey]

Would you have it complain that commands.mli,v, RCS/commands.mli,v,
RCS/commands.mli, s.commands.mli and SCCS/s.commands.mli were missing?

> Not really in this use case.

Did you tell make, then, to disable all of its default rules for creating 
commands.mli or, for that matter, commands.cmo, by checking them out of version 
control?

Can an error message like “The target “commands.cmo” could not be built
because the specified dependency “commands.mli” did not exist.”
be more appropriate instead of the message “make: Nothing to be done
for 'commands.cmo'.”?

On Jun 14, 2017, at 23:12, SF Markus Elfring 
> wrote:

I have noticed a moment ago that an interface description file was missing
somehow for the OCaml source file in this compilation attempt.
...
I wonder then that the make tool did not give me a direct clue for a failed
software dependency as I am used to in other cases.
Would you have it complain that commands.mli,v, RCS/commands.mli,v,
RCS/commands.mli, s.commands.mli and SCCS/s.commands.mli were missing?

Not really in this use case.


The existence of any of those would have let make build commands.mli, hence 
commands.cmo.

This interface description file could also be generated by a command variant
of the OCaml compiler. But it seems that it is finally not needed for
the build scripts which I am trying to update.


Can you come up with a specification for finding which of the possible
missing dependencies is the one that you actually care about?

Can an error message like “The target “commands.cmo” could not be built
because the specified dependency “commands.mli” did not exist.”
be more appropriate instead of the message “make: Nothing to be done
for 'commands.cmo'.”?

Regards,
Markus
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[SF Markus Elfring]

>> I have noticed a moment ago that an interface description file was missing
>> somehow for the OCaml source file in this compilation attempt.
> ...
>> I wonder then that the make tool did not give me a direct clue for a failed
>> software dependency as I am used to in other cases.
> Would you have it complain that commands.mli,v, RCS/commands.mli,v,
> RCS/commands.mli, s.commands.mli and SCCS/s.commands.mli were missing?

Not really in this use case.


> The existence of any of those would have let make build commands.mli, hence 
> commands.cmo.

This interface description file could also be generated by a command variant
of the OCaml compiler. But it seems that it is finally not needed for
the build scripts which I am trying to update.


> Can you come up with a specification for finding which of the possible
> missing dependencies is the one that you actually care about?

Can an error message like “The target “commands.cmo” could not be built
because the specified dependency “commands.mli” did not exist.”
be more appropriate instead of the message “make: Nothing to be done
for 'commands.cmo'.”?

Regards,
Markus

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[SF Markus Elfring]

> (I would guess that most of the people on the bug-make mailing list have 
> never worked with ocaml and therefore don't know what needs to be done to 
> build it.)

Yesterday I realised that one source source file needed a special handling
in the mentioned subdirectory.


> The snippet of Makefile you provided didn't include any rules for
> building "commands.ml", so I don't understand why you expect make to build it.

The suffix “ml” denotes a source file in this use case.

I needed another moment to become really aware that this software module
is a bit special. It seems that it is intended that it will be compiled
without a corresponding interface description file (suffix “mli”).

Regards,
Markus

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Checking software build tries for “commands.cmo”

[Martin Dorey]

> I have noticed a moment ago that an interface description file was missing
> somehow for the OCaml source file in this compilation attempt.
...
> I wonder then that the make tool did not give me a direct clue for a failed
> software dependency as I am used to in other cases.

Would you have it complain that commands.mli,v, RCS/commands.mli,v, 
RCS/commands.mli, s.commands.mli and SCCS/s.commands.mli were missing?  The 
existence of any of those would have let make build commands.mli, hence 
commands.cmo.  You can have it do that, with make --debug=all.  You'll see it 
tries harder than you'd imagine, even searching for a rule that could update 
your makefile to fix the problem.  Can you come up with a specification for 
finding which of the possible missing dependencies is the one that you actually 
care about?
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[Philip Guenther]

On Tue, 13 Jun 2017, SF Markus Elfring wrote:
> I am testing the following pattern rules with the program “GNU Make 4.2.1-1.7”
> on my openSUSE Tumbleweed system as I would like to adjust some areas
> in affected make scripts for another evolving software tool.
> 
> …
> %.cmi: %.mli
>   $(OCAMLC_CMD) -c $<
> 
> %.cmo: %.ml %.cmi
>   $(OCAMLC_CMD) -c $<
> 
> %.cmx: %.ml %.cmi
>   $(OCAMLOPT_CMD) -c $<
> …
> 
> I have tried a specific command out.
> 
> elfring@Sonne:~/Projekte/Coccinelle/20160205/commons> LANG=C make -d 
> common.cmo V=1 
...
> This test showed the expected results.

Two questions:
1) What files were present in the directory before you ran that command?
2) What _was_ that expected result?

(I would guess that most of the people on the bug-make mailing list have 
never worked with ocaml and therefore don't know what needs to be done to 
build it.)


> I have tried another command variant out.
> 
> elfring@Sonne:~/Projekte/Coccinelle/20160205/commons> LANG=C make -d 
> commands.cmo V=1
...
> Now I wonder why I do not get the desired software generation results for
> this test case. Why is the source file “commands.ml” not compiled again
> in the way as the other one?

The snippet of Makefile you provided didn't include any rules for building 
"commands.ml", so I don't understand why you expect make to build it.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[SF Markus Elfring]

> elfring@Sonne:~/Projekte/Coccinelle/20160205/commons> LANG=C make -d 
> commands.cmo V=1
> …
>  No implicit rule found for 'commands.cmo'.
>  Finished prerequisites of target file 'commands.cmo'.
> Must remake target 'commands.cmo'.
> Successfully remade target file 'commands.cmo'.
> make: Nothing to be done for 'commands.cmo'.
> 
> 
> Now I wonder why I do not get the desired software generation results for
> this test case. Why is the source file “commands.ml” not compiled again
> in the way as the other one?

I have noticed a moment ago that an interface description file was missing
somehow for the OCaml source file in this compilation attempt.

I have added the following extra rules as a special handling.


commands.cmo: commands.ml
$(OCAMLC_CMD) -c $<

commands.cmx: commands.ml
$(OCAMLOPT_CMD) -c $<


I wonder then that the make tool did not give me a direct clue for a failed
software dependency as I am used to in other cases.

Regards,
Markus

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make