From: David Allsopp <dra-news@metastack.com>
To: SF Markus Elfring <elfring@users.sourceforge.net>
Cc: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: RE: [Caml-list] Development status of the dependency generator for OCaml
Date: Fri, 21 Jul 2017 16:16:04 +0000 [thread overview]
Message-ID: <E51C5B015DBD1348A1D85763337FB6D9014D5206DE@Remus.metastack.local> (raw)
In-Reply-To: <3a62b0f1-0004-a6fb-8c53-8fe961aafa57@users.sourceforge.net>
Markus Elfring wrote:
> >>> What are you regarding as erroneous about the entries with "only a
> >>> dependency on a single compiled module interface"
> >>> (for bytecode, that sounds correct to me).
> >>
> >> A software build system which can support the programming language
> “OCaml”
> >> to some some degree will contain generation rules for involved file
> >> types as you mentioned it also.
> >
> > I'm not clear how what you say relates to my question about
>
> If you can tolerate that specific dependency specifications (like for ML
> and MLI files) can be missing, …
They're not missing - they're simply obviously and necessary as part of your Makefile rules because somewhere you need a recipe to build the files.
> > what you were finding erroneous.
>
> … I find it questionable to repeat information for some CMO/CMX files when
> the corresponding details should be expressed by software build rules
> already.
It's pretty well-specified behaviour of make, though.
<snip>
> >>> foo.cmi:
> >>> foo.cmo: foo.cmi
> >>>
> >>> should simply not be printed, and be assumed to work with implicit
> >> rules?
> >>
> >> Yes. - In principle for the default data export variant.
> >
> > For the second example, the default is very clearly not going to
> > change (since ocamldep already exists).
>
> Can further feature requests adjust the discussed software situation a bit
> more?
>
> * “ocamldep -all” does not express dependencies on MLI files.
> https://caml.inria.fr/mantis/view.php?id=7593
>
> * It seems that the main developers have got communication difficulties
> with my style of clarification requests (or bug reports).
Your descriptions are, I'm afraid, vague, don't give a simple repro case, or the output you're expecting. For this particular PR, I'm afraid it looks like you blew Xavier's fuse at line 1. For example:
Summary: .cmi files do not depend on .mli in output of ocamldep -all
Description: ocamldep -all is supposed to include all dependencies in its output, but this doesn't appear to apply to .mli files.
Steps to reproduce:
<pre>
DRA@Phantasos $ touch foo.mli
DRA@Phantasos $ ocamldep -all foo.mli
foo.cmi :
</pre>
Additional information:
Expected output:
<pre>
foo.cmi : foo.mli
</pre>
I don't know if changing that behaviour to include .mli dependency causes problems (I don't think it does) - it's why I originally said it surprised me, rather than that it was definitely a bug. However, given the odd ways in which .cmi files can be generated, I wonder if there is a subtle reason why depending on the .mli file may be hard to decide...
> > Personally, I'd find it very irritating to have to remember to add
> > %.cmo: %.cmi to my Makefiles
>
> If you are using such make scripts, you have to specify make rules so that
> the desired OCaml commands will be called.
No - those rules will map %.cmo: %.ml or %.cmi: %.mli, there are no actions associated with %.cmo: %.cmi and hence no need for me to write it.
> > (I'd already be irritated, as it would imply I was not using jbuilder,
> > but that's a separate story...)
> Do you prefer to use more advanced software development environments?
Ah, you may have hit on a slight naming problem: I mean https://github.com/janestreet/jbuilder, not an old Java IDE...
David
next prev parent reply other threads:[~2017-07-21 16:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-18 19:21 SF Markus Elfring
2017-07-21 9:19 ` David Allsopp
2017-07-21 11:30 ` SF Markus Elfring
2017-07-21 13:01 ` David Allsopp
2017-07-21 15:50 ` SF Markus Elfring
2017-07-21 16:16 ` David Allsopp [this message]
2017-07-21 17:07 ` SF Markus Elfring
2017-07-25 18:13 ` [Caml-list] Addition of a data export variant containing only required extensions for build dependency specifications SF Markus Elfring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E51C5B015DBD1348A1D85763337FB6D9014D5206DE@Remus.metastack.local \
--to=dra-news@metastack.com \
--cc=caml-list@inria.fr \
--cc=elfring@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox