[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Philip Guenther
Subject: Re: Checking software build tries for “commands.cmo”
Date: Fri, 16 Jun 2017 20:40:10 -0700
User-agent: Alpine 2.21 (BSO 202 2017-01-01)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]