[Caml-list] Obtaining module dependencies from within OCamlbuild plugin

[Caml-list] Obtaining module dependencies from within OCamlbuild plugin

[Dario Teixeira]

Hi,

I'm trying to manipulate a project's dependencies from within an 
OCamlbuild
plugin, and one prerequisite is obtaining the current set of 
dependencies
for a given module.  For instance, to obtain the set of dependencies for
module "src/foo_c.ml", one could expect to invoke the following from 
within
the After_rules hook of myocamlbuild.ml:

   Command.deps_of_tags (tags_of_pathname "src/foo_c.ml")

This always returns an empty list, however.  The same holds if one tries
to narrow the list of tags to just the filename:

   Command.deps_of_tags (Tags.of_list ["file:src/foo_c.ml"])

One possible explanation for this behaviour is that the set of 
dependencies
has not been computed yet when the After_rules hook is invoked.  Is that 
the
case, or am I missing something altogether different?  Either way, how 
do I
obtain the set of dependencies?

Thanks in advance for your attention!
Kind regards,
Dario Teixeira

Re: [Caml-list] Obtaining module dependencies from within OCamlbuild plugin

[Gabriel Scherer]

In OCamlbuild, most of the dependencies are detected dynamically while
the compilation runs (typically the process of producing a target (eg.
foo.cma) will run code that will decide to recursively produce lots of
targets (eg. modules listed in foo.mllib), and those are the dynamic
dependencies). Command_deps_of_tags returns the static dependencies
that have been specified by tags, by using Command.dep and
Command.pdep to associate dependencies to specific tags.

You cannot obtain the set of dependencies of a target without actually
trying to build it. (If you were interested in this for performance
reason, a reasonable idea would be to cache the dependencies of the
last build and replay them optimistically, but I assume that's not
your point here.)


On Tue, Feb 3, 2015 at 9:01 PM, Dario Teixeira
<dario.teixeira@nleyten.com> wrote:
> Hi,
>
> I'm trying to manipulate a project's dependencies from within an OCamlbuild
> plugin, and one prerequisite is obtaining the current set of dependencies
> for a given module.  For instance, to obtain the set of dependencies for
> module "src/foo_c.ml", one could expect to invoke the following from within
> the After_rules hook of myocamlbuild.ml:
>
>   Command.deps_of_tags (tags_of_pathname "src/foo_c.ml")
>
> This always returns an empty list, however.  The same holds if one tries
> to narrow the list of tags to just the filename:
>
>   Command.deps_of_tags (Tags.of_list ["file:src/foo_c.ml"])
>
> One possible explanation for this behaviour is that the set of dependencies
> has not been computed yet when the After_rules hook is invoked.  Is that the
> case, or am I missing something altogether different?  Either way, how do I
> obtain the set of dependencies?
>
> Thanks in advance for your attention!
> Kind regards,
> Dario Teixeira
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Obtaining module dependencies from within OCamlbuild plugin

[Dario Teixeira]

Hi Gabriel,

> In OCamlbuild, most of the dependencies are detected dynamically while
> the compilation runs (typically the process of producing a target (eg.
> foo.cma) will run code that will decide to recursively produce lots of
> targets (eg. modules listed in foo.mllib), and those are the dynamic
> dependencies). Command_deps_of_tags returns the static dependencies
> that have been specified by tags, by using Command.dep and
> Command.pdep to associate dependencies to specific tags.

Yeah, I was already afraid that was the case.  There is of course an
alternative strategy that could have been used instead: compute all the
dependencies (by recursively invoking OCamldep et al) before starting 
the
compilation proper.  Each strategy has its advantages and disadvantages,
of course.


> You cannot obtain the set of dependencies of a target without actually
> trying to build it. (If you were interested in this for performance
> reason, a reasonable idea would be to cache the dependencies of the
> last build and replay them optimistically, but I assume that's not
> your point here.)

As I'm sure you've guessed, my interest in this problem derives from
no-alias-deps + module aliases, not performance... (see reply to the
other related message)

Kind regards,
Dario Teixeira