[Caml-list] Forcing OCamlbuild to compile a file before another

[Caml-list] Forcing OCamlbuild to compile a file before another

[Dario Teixeira]

Hi,

How does one force OCamlbuild to compile a file before another
when it cannot automatically infer their dependency?

For instance, compilation fails because OCamlbuild tries to compile
lambwiki_parser.mly before lambwiki.ml. To get around it, I added
the following to the "After_rules" of my dispatcher:

dep ["menhir"; "file:lambwiki_parser.mly"] ["lambwiki.cmo"]

My assumption was that this told OCamlbuild that using Menhir to
compile file lambwiki_parser.mly added an explicit dependency
on lambwiki.cmo (which in turn can be obtained by compiling
lambwiki.ml).  This doesn't work, however, so perhaps my
mental model of how OCamlbuild works is not correct.

Any ideas on how to get this to work as intended?

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

Re: [Caml-list] Forcing OCamlbuild to compile a file before another

[Francois Pottier]

Hello,

On Fri, Jan 23, 2015 at 03:08:23PM +0000, Dario Teixeira wrote:
> How does one force OCamlbuild to compile a file before another
> when it cannot automatically infer their dependency?

I am not sure. But: why isn't the dependency explicit in
lambwiki_parser.mly? Doesn't it mention the module name
"Lambwiki" somewhere? If not, perhaps you could add a
fake dependency by declaring "module L = LambWiki" at
the top of lambwiki_parser.mly. Would that help?

-- 
François Pottier
Francois.Pottier@inria.fr
http://gallium.inria.fr/~fpottier/

Re: [Caml-list] Forcing OCamlbuild to compile a file before another

[Dario Teixeira]

Hi,

> I am not sure. But: why isn't the dependency explicit in
> lambwiki_parser.mly? Doesn't it mention the module name
> "Lambwiki" somewhere? If not, perhaps you could add a
> fake dependency by declaring "module L = LambWiki" at
> the top of lambwiki_parser.mly. Would that help?

I'm still poking at it, but it seems there may be a bug in OCamlbuild,
or at least a difference of opinion. (I am using module aliases and
-no-alias-deps, and some of these waters are uncharted).

In the tags file, I had declared a tag "open(Lambwiki)" for file
<lambwiki_parser.mly>.  I assumed this would automatically add a
dependency on lambwiki.ml for lambwiki_parser.mly.

Now, lambwiki.ml contains only module aliases, for instance:

module Parser = Lambwiki_parser
module Scanner = Lambwiki_scanner

To avoid a circular dependency, in myocamlbuild I use the non_dependency
function (part of OCamlbuild's API) to declare that lambwiki.ml does not
in fact depend on Lambwiki_parser and Lambwiki_scanner.

I wonder if the tooling expects module aliases to produce dependencies
the other way around, ie, Lambwiki_parser depends on Lambwiki but not
vice-versa.  This is not clear to me.

Anyway, adding a dummy dependency as you suggested does the trick for
this particular problem.

Kind regards,
Dario Teixeira

Re: [Caml-list] Forcing OCamlbuild to compile a file before another

[Gabriel Scherer]

[-- Attachment #1: Type: text/plain, Size: 3308 bytes --]

Currently there is nothing specific in ocamlbuild to support
-no-alias-deps. What the open(Foo) flag does is to to pass the "-open Foo"
option to ocamldep, which in turns merely adds Foo to the list of
dependencies of the compiled module. My understand of the situation is that
it guarantees that project using "-open ..." in their build system will
build correctly with ocamlbuild, with two limitations:
(1) if you use crazy recursive-but-not-really schemes, you'll get a
circular dependencies error
(2) if Foo is a list of aliases, it will act as a bottleneck in the
dependency graph

Any good proposal to change the statu quo will of course be considered --
but I myself have little time to implement new OCamlbuild features -- and I
will try to be as reactive on possible bugs (eg. #6755) as possible, as the
de-facto maintainer of ocamlbuild.

I am not sure what should be done about (1). The almost-recursive scheme
was adopted by Jane Street for the extremely specific use-case of migrating
an enormous code-base from -pack to -no-alias-deps, but I am not sure it is
reasonable to expect it to work for other users (and I doubt it's wise to
advertise it as such).

In slightly more details: I think the idea of distributing a
short-name-giving lambwiki.ml to your users is a good way to emulate -pack
without the downsides of -pack, but that you could avoid using the short
names in the project itself (that is use Lambda_Parser explicitly rather
than Parser). If you did this, the spurious cyclic dependencies disappaear,
you can simply use ocamlbuild without any dependency hack, and your users
see the short names.

On Fri, Jan 23, 2015 at 8:09 PM, Dario Teixeira <dario.teixeira@nleyten.com>
wrote:

> Hi,
>
>  I am not sure. But: why isn't the dependency explicit in
>> lambwiki_parser.mly? Doesn't it mention the module name
>> "Lambwiki" somewhere? If not, perhaps you could add a
>> fake dependency by declaring "module L = LambWiki" at
>> the top of lambwiki_parser.mly. Would that help?
>>
>
> I'm still poking at it, but it seems there may be a bug in OCamlbuild,
> or at least a difference of opinion. (I am using module aliases and
> -no-alias-deps, and some of these waters are uncharted).
>
> In the tags file, I had declared a tag "open(Lambwiki)" for file
> <lambwiki_parser.mly>.  I assumed this would automatically add a
> dependency on lambwiki.ml for lambwiki_parser.mly.
>
> Now, lambwiki.ml contains only module aliases, for instance:
>
> module Parser = Lambwiki_parser
> module Scanner = Lambwiki_scanner
>
> To avoid a circular dependency, in myocamlbuild I use the non_dependency
> function (part of OCamlbuild's API) to declare that lambwiki.ml does not
> in fact depend on Lambwiki_parser and Lambwiki_scanner.
>
> I wonder if the tooling expects module aliases to produce dependencies
> the other way around, ie, Lambwiki_parser depends on Lambwiki but not
> vice-versa.  This is not clear to me.
>
> Anyway, adding a dummy dependency as you suggested does the trick for
> this particular problem.
>
> 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
>

[-- Attachment #2: Type: text/html, Size: 4536 bytes --]

Re: [Caml-list] Forcing OCamlbuild to compile a file before another

[Dario Teixeira]

Hi Gabriel,

> Currently there is nothing specific in ocamlbuild to support
> -no-alias-deps. What the open(Foo) flag does is to to pass the "-open
> Foo" option to ocamldep, which in turns merely adds Foo to the list of
> dependencies of the compiled module. My understand of the situation
> is that it guarantees that project using "-open ..." in their build
> system will build correctly with ocamlbuild, with two limitations:
> (1) if you use crazy recursive-but-not-really schemes, you'll get a
> circular dependencies error (2) if Foo is a list of aliases, it will
> act as a bottleneck in the dependency graph

I've opted to abandon "-open Foo" and now explicitly declare "open Foo" 
on the
source-code itself.  Besides avoiding issues with the build system, I 
think
the explicit approach will end up being clearer for someone reading the 
code
(less knowledge about the system outside the source code itself).


> Any good proposal to change the statu quo will of course be considered
> -- but I myself have little time to implement new OCamlbuild features 
> --
> and I will try to be as reactive on possible bugs (eg. #6755) as 
> possible,
> as the de-facto maintainer of ocamlbuild.

Yeap, I understand.  The good news is that it should be possible to use
module-aliases/no-aliases-deps/pseudo-circular-recursion within the 
current
OASIS+OCamlbuild framework with only minimal extra burden on the user,
and zero modifications to OASIS or OCamlbuild.

I had to bump my forehead against the wall a few times, but in the end 
I've
managed to get the full combination working on a toy example, and I'm 
confident
I can also get it to work on the much larger Lambdoc code base.  I'll 
keep
you posted...


> I am not sure what should be done about (1). The almost-recursive
> scheme was adopted by Jane Street for the extremely specific use-case
> of migrating an enormous code-base from -pack to -no-alias-deps, but
> I am not sure it is reasonable to expect it to work for other users
> (and I doubt it's wise to advertise it as such).

In my particular case, the impetus to abandon module packs stemmed not 
so
much from the fat-binaries and recompilation problems, but from issues 
with
the tooling (namely OCamldoc).  Either way, there are enough advantages 
to
module aliases and -no-alias-deps that I suspect more people will want 
to
use them, even if they are not widely advertised.


> In slightly more details: I think the idea of distributing a
> short-name-giving lambwiki.ml to your users is a good way to emulate
> -pack without the downsides of -pack, but that you could avoid using 
> the
> short names in the project itself (that is use Lambda_Parser explicitly
> rather than Parser). If you did this, the spurious cyclic dependencies
> disappaear, you can simply use ocamlbuild without any dependency hack,
> and your users see the short names.

Yeah, using long names internally and short names externally is my 
fallback
scenario.  However, the Lambdoc core modules are used so extensively 
from
within the library that it's worth spending some time trying to get 
short
names to work internally too.

Kind regards,
Dario Teixeira

Re: [Caml-list] Forcing OCamlbuild to compile a file before another

[Dario Teixeira]

Hi again,

> Yeap, I understand.  The good news is that it should be possible to use
> module-aliases/no-aliases-deps/pseudo-circular-recursion within the 
> current
> OASIS+OCamlbuild framework with only minimal extra burden on the user,
> and zero modifications to OASIS or OCamlbuild.
> 
> I had to bump my forehead against the wall a few times, but in the end 
> I've
> managed to get the full combination working on a toy example, and I'm 
> confident
> I can also get it to work on the much larger Lambdoc code base.  I'll 
> keep
> you posted...

(replying to myself here)

I may have spoken too soon on the ease of tweaking a build system based 
on
OASIS + OCamlbuild to work with module aliases and -no-alias-deps: the 
toy
example does compile from scratch, but the build system gets confused by
subsequent modifications to source files.

I have created a branch in the Lambdoc repo for experimenting with this
process [1].  If you try to compile it, it almost works, but you do get
lots of nasty warnings and a generally confused build system.

Kind regards,
Dario Teixeira

[1] https://github.com/darioteixeira/lambdoc/tree/oasification

Re: [Caml-list] Forcing OCamlbuild to compile a file before another

[Gabriel Scherer]

I haven't given much thought to it yet, but here would a sketchy idea
of how to better support -no-alias-deps in OCamlbuild:

ocamldep) extend ocamldep with a new -paths (as an extension over
-modules) that returns not just the modules M appearing at the
beginning of paths in source files, but the full module-longident (eg.
M.Foo.Bar if you access the value M.Foo.Bar.baz or constructor
M.Foo.Bar.Foobar)

ocamlbuild) use ocamldep -modules (this happens in
ocaml_utils.ml:read_path_dependencies), and for a non-singleton path
of the form Foo.Bar, first type-check the compilation unit Foo, then
inspect the .cmi to know whether Bar is defined as a module alias of
Foo, and in that case depend on the aliased compilation unit

(This should be done as a modification to the tool itself rather than
a plugin, I think.)

On Mon, Jan 26, 2015 at 1:30 PM, Dario Teixeira
<dario.teixeira@nleyten.com> wrote:
> Hi again,
>
>> Yeap, I understand.  The good news is that it should be possible to use
>> module-aliases/no-aliases-deps/pseudo-circular-recursion within the
>> current
>> OASIS+OCamlbuild framework with only minimal extra burden on the user,
>> and zero modifications to OASIS or OCamlbuild.
>>
>> I had to bump my forehead against the wall a few times, but in the end
>> I've
>> managed to get the full combination working on a toy example, and I'm
>> confident
>> I can also get it to work on the much larger Lambdoc code base.  I'll keep
>> you posted...
>
>
> (replying to myself here)
>
> I may have spoken too soon on the ease of tweaking a build system based on
> OASIS + OCamlbuild to work with module aliases and -no-alias-deps: the toy
> example does compile from scratch, but the build system gets confused by
> subsequent modifications to source files.
>
> I have created a branch in the Lambdoc repo for experimenting with this
> process [1].  If you try to compile it, it almost works, but you do get
> lots of nasty warnings and a generally confused build system.
>
> Kind regards,
> Dario Teixeira
>
> [1] https://github.com/darioteixeira/lambdoc/tree/oasification
>
>
>
> --
> 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] Forcing OCamlbuild to compile a file before another

[Dario Teixeira]

Hello again Gabriel,

> I haven't given much thought to it yet, but here would a sketchy idea
> of how to better support -no-alias-deps in OCamlbuild:
> 
> ocamldep) extend ocamldep with a new -paths (as an extension over
> -modules) that returns not just the modules M appearing at the
> beginning of paths in source files, but the full module-longident (eg.
> M.Foo.Bar if you access the value M.Foo.Bar.baz or constructor
> M.Foo.Bar.Foobar)
> 
> ocamlbuild) use ocamldep -modules (this happens in
> ocaml_utils.ml:read_path_dependencies), and for a non-singleton path
> of the form Foo.Bar, first type-check the compilation unit Foo, then
> inspect the .cmi to know whether Bar is defined as a module alias of
> Foo, and in that case depend on the aliased compilation unit
> 
> (This should be done as a modification to the tool itself rather than
> a plugin, I think.)

Yes, I agree that all these tweaks to support -no-alias-deps should
ideally be part of OCamlbuild+OCamldep and work out-of-the-box.
Moreover, the modifications you suggest are in line with what I'm
planning to implement as a myocamlbuild plugin (I'll have to do it
as a plugin because I don't want to wait for a future OCaml release).

The table below lists the dependencies of my dummy project, as computed
by the alias-oblivious OCamldep and what they actually are:

                 OCamldep:                       Actual:

Foo.ml:         Foo_a, Foo_b, Foo_c             (none)
Foo_a.ml:       Foo                             Foo
Foo_b.ml:       Foo, A                          Foo, Foo_a
Foo_c.ml:       Foo, A, B                       Foo, Foo_a, Foo_b

So basically I'll postprocess the output of OCamldep: whenever it finds
that a module depends both on Foo and on an alias declared in Foo, then
I'll replace the alias with the actual module.  In addition, all of 
Foo's
dependencies must be cleared as well (it's more practical to just invoke
non_dependency for this purpose).

My initial idea was to manipulate the dependency graph instead of 
resorting
to postprocessing OCamldep's output.  Alas, as you made clear on your 
other
message, OCamlbuild does not actually construct a dependency graph 
before
the "real" compilation starts.

Thanks again for your time!
Kind regards,
Dario Teixeira

Re: [Caml-list] Forcing OCamlbuild to compile a file before another

[Gabriel Scherer]

I thought a bit more about this and here is a plan that seems
reasonable (I fact-checked it with Pierre Chambart and Benoît Vaugon)
and does not require changing ocamldep.

1) add a notion of foo.mlalias files with content of the form

  M := Foo_M
  Z := Bar_Z
  ...

  with a rule .mlalias -> .cmi that generates the .ml and compiles it
with -no-alias-deps (note that by design it never has any dependency)

2) add the following rules in the code that computes dependencies from
the output of ocamldep:
      if the module depends on Foo (which is the name of an alias
file) and M, and (M := Bar) is in foo.mlalias, then also add Bar as a
dependency

This should solve the problem of false cyclic dependencies caused by
using short names inside the project itself.


Remarks:

- I considered, instead of a .mlalias file with a specific syntax,
allowing to tag any .ml file as an alias-giving files; that makes the
system more complex, because the alias-giving files may contain other
OCaml statements than alias definitions, and thus have some
dependencies (and we don't want to get in the business of trying to
guess which modules are just aliases or real dependencies, or having
to inspect .cmi files after-the-fact to rebuild the aliasing map). The
downside is that people with an existing -no-alias-deps scheme
suddenly willing to use ocamlbuild would have to rewrite some stuff
first. (The other direction can be made automatic by a .mlalias ->
.ml.inferred rule)

- The restriction that the .mlalias file only contains module aliases
and not other things you might want to have in a prelude/header is not
really a restriction, as "include Foo" (where Foo is the name of the
aliases-defining module) should work. I have not tested it, though.

- It might be possible to implement this at the plugin level. The
.mlalias rule could be proposed as a plugin. I'm less confident about
the dependency-mangling logic, but the idea would be to overload the
existing ".ml -> .ml.depends" rule to change the .ml.depends result
(instead of its interpretation by ocamlbuild as I had in mind above).

On Wed, Feb 4, 2015 at 2:18 PM, Dario Teixeira
<dario.teixeira@nleyten.com> wrote:
> Hello again Gabriel,
>
>> I haven't given much thought to it yet, but here would a sketchy idea
>> of how to better support -no-alias-deps in OCamlbuild:
>>
>> ocamldep) extend ocamldep with a new -paths (as an extension over
>> -modules) that returns not just the modules M appearing at the
>> beginning of paths in source files, but the full module-longident (eg.
>> M.Foo.Bar if you access the value M.Foo.Bar.baz or constructor
>> M.Foo.Bar.Foobar)
>>
>> ocamlbuild) use ocamldep -modules (this happens in
>> ocaml_utils.ml:read_path_dependencies), and for a non-singleton path
>> of the form Foo.Bar, first type-check the compilation unit Foo, then
>> inspect the .cmi to know whether Bar is defined as a module alias of
>> Foo, and in that case depend on the aliased compilation unit
>>
>> (This should be done as a modification to the tool itself rather than
>> a plugin, I think.)
>
>
> Yes, I agree that all these tweaks to support -no-alias-deps should
> ideally be part of OCamlbuild+OCamldep and work out-of-the-box.
> Moreover, the modifications you suggest are in line with what I'm
> planning to implement as a myocamlbuild plugin (I'll have to do it
> as a plugin because I don't want to wait for a future OCaml release).
>
> The table below lists the dependencies of my dummy project, as computed
> by the alias-oblivious OCamldep and what they actually are:
>
>                 OCamldep:                       Actual:
>
> Foo.ml:         Foo_a, Foo_b, Foo_c             (none)
> Foo_a.ml:       Foo                             Foo
> Foo_b.ml:       Foo, A                          Foo, Foo_a
> Foo_c.ml:       Foo, A, B                       Foo, Foo_a, Foo_b
>
> So basically I'll postprocess the output of OCamldep: whenever it finds
> that a module depends both on Foo and on an alias declared in Foo, then
> I'll replace the alias with the actual module.  In addition, all of Foo's
> dependencies must be cleared as well (it's more practical to just invoke
> non_dependency for this purpose).
>
> My initial idea was to manipulate the dependency graph instead of resorting
> to postprocessing OCamldep's output.  Alas, as you made clear on your other
> message, OCamlbuild does not actually construct a dependency graph before
> the "real" compilation starts.
>
> Thanks again for your time!
> 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] Forcing OCamlbuild to compile a file before another

[Dario Teixeira]

Hi,

> I thought a bit more about this and here is a plan that seems
> reasonable (I fact-checked it with Pierre Chambart and Benoît Vaugon)
> and does not require changing ocamldep.
> 
> 1) add a notion of foo.mlalias files with content of the form
> 
>   M := Foo_M
>   Z := Bar_Z
>   ...
> 
>   with a rule .mlalias -> .cmi that generates the .ml and compiles it
> with -no-alias-deps (note that by design it never has any dependency)

This seems reasonable.  In a sense, modules like foo.ml whose contents
are just a list of aliases are already "special" in a way, and this
convention emphasises that.  Moreover, it has an added documentation
advantage: simply by listing mlalias files a newcomer may familiarise
themselves with the module aliases used in a project.


> 2) add the following rules in the code that computes dependencies from
> the output of ocamldep:
>       if the module depends on Foo (which is the name of an alias
> file) and M, and (M := Bar) is in foo.mlalias, then also add Bar as a
> dependency

And, I presume, also remove M from the module's dependency list, right?


> - I considered, instead of a .mlalias file with a specific syntax,
> allowing to tag any .ml file as an alias-giving files; that makes the
> system more complex, because the alias-giving files may contain other
> OCaml statements than alias definitions, and thus have some
> dependencies (and we don't want to get in the business of trying to
> guess which modules are just aliases or real dependencies, or having
> to inspect .cmi files after-the-fact to rebuild the aliasing map). The
> downside is that people with an existing -no-alias-deps scheme
> suddenly willing to use ocamlbuild would have to rewrite some stuff
> first. (The other direction can be made automatic by a .mlalias ->
> .ml.inferred rule)

Yeah, I see no need to overcomplicate this.


> (...)
> - It might be possible to implement this at the plugin level. The
> .mlalias rule could be proposed as a plugin. I'm less confident about
> the dependency-mangling logic, but the idea would be to overload the
> existing ".ml -> .ml.depends" rule to change the .ml.depends result
> (instead of its interpretation by ocamlbuild as I had in mind above).

It would be of course nice if all this logic made its way into 4.03
or 4.02.2 as part of OCamlbuild's builtins.  Regardless, from my
perspective of someone who's not familiar with OCamlbuild's code
base and inner workings, I think the most straightforward interim
solution will be along the lines of what I described in my previous
message: write a plugin that postprocesses OCamldep's output.  Which
leads me to the question: is it feasible to do the postprocessing
in OCamlbuild, or will I have to write an external script that does
the postprocessing and gets invoked by setting Options.ocamldep?

Kind regards,
Dario Teixeira

Re: [Caml-list] Forcing OCamlbuild to compile a file before another

[Gabriel Scherer]

> And, I presume, also remove M from the module's dependency list, right?

That's not correct in the general case. Consider for example:

  bar.ml: ...

  long_bar.ml: ...

  foo.mlalias:
    Bar := Long_bar

  example.ml:
    include Bar
    open Foo
    include Bar

On the contrary, *over*-approximating the dependencies (what happens
in the sane situations where M really isn't a dependency, only its
long form) should be harmless and is already done by ocamldep anyway
(as soon as a you open a module that has submodules and use them, they
get listed as extraneous dependencies).

> Which leads me to the question: is it feasible to do the postprocessing
> in OCamlbuild, or will I have to write an external script that does
> the postprocessing and gets invoked by setting Options.ocamldep?

You can add new rules in a plugin (eg. one for .mlalias files), and
override existing rules by playing with priority levels (which is a
kind of dubious business but well...). If you override the ".ml ->
.ml.depends" rule (see "ocaml dependencies ml" in
ocamlbuild/ocaml_specific.ml, you can replace the current ocamldep
invocation by a command that invokes ocamldep and does the
preprocessing you want.
I suspect that the easier route depends on how you want to specify the
logic of which dependencies to remove. If you're happy with listing
manually the aliases of your particular project, then just giving them
to an external script would probably be easier (sitting inside
OCamlbuild don't bring you much because you don't need access to its
information) -- note that you can override the ocamldep command from
inside myocamlbuild.ml. If you want a somewhat generic mechanism like
recognizing .mlalias files, then the ocamlbuild codebase may be of
help.

On Wed, Feb 4, 2015 at 5:15 PM, Dario Teixeira
<dario.teixeira@nleyten.com> wrote:
> Hi,
>
>> I thought a bit more about this and here is a plan that seems
>> reasonable (I fact-checked it with Pierre Chambart and Benoît Vaugon)
>> and does not require changing ocamldep.
>>
>> 1) add a notion of foo.mlalias files with content of the form
>>
>>   M := Foo_M
>>   Z := Bar_Z
>>   ...
>>
>>   with a rule .mlalias -> .cmi that generates the .ml and compiles it
>> with -no-alias-deps (note that by design it never has any dependency)
>
>
> This seems reasonable.  In a sense, modules like foo.ml whose contents
> are just a list of aliases are already "special" in a way, and this
> convention emphasises that.  Moreover, it has an added documentation
> advantage: simply by listing mlalias files a newcomer may familiarise
> themselves with the module aliases used in a project.
>
>
>> 2) add the following rules in the code that computes dependencies from
>> the output of ocamldep:
>>       if the module depends on Foo (which is the name of an alias
>> file) and M, and (M := Bar) is in foo.mlalias, then also add Bar as a
>> dependency
>
>
> And, I presume, also remove M from the module's dependency list, right?
>
>
>> - I considered, instead of a .mlalias file with a specific syntax,
>> allowing to tag any .ml file as an alias-giving files; that makes the
>> system more complex, because the alias-giving files may contain other
>> OCaml statements than alias definitions, and thus have some
>> dependencies (and we don't want to get in the business of trying to
>> guess which modules are just aliases or real dependencies, or having
>> to inspect .cmi files after-the-fact to rebuild the aliasing map). The
>> downside is that people with an existing -no-alias-deps scheme
>> suddenly willing to use ocamlbuild would have to rewrite some stuff
>> first. (The other direction can be made automatic by a .mlalias ->
>> .ml.inferred rule)
>
>
> Yeah, I see no need to overcomplicate this.
>
>
>> (...)
>> - It might be possible to implement this at the plugin level. The
>> .mlalias rule could be proposed as a plugin. I'm less confident about
>> the dependency-mangling logic, but the idea would be to overload the
>> existing ".ml -> .ml.depends" rule to change the .ml.depends result
>> (instead of its interpretation by ocamlbuild as I had in mind above).
>
>
> It would be of course nice if all this logic made its way into 4.03
> or 4.02.2 as part of OCamlbuild's builtins.  Regardless, from my
> perspective of someone who's not familiar with OCamlbuild's code
> base and inner workings, I think the most straightforward interim
> solution will be along the lines of what I described in my previous
> message: write a plugin that postprocesses OCamldep's output.  Which
> leads me to the question: is it feasible to do the postprocessing
> in OCamlbuild, or will I have to write an external script that does
> the postprocessing and gets invoked by setting Options.ocamldep?
>
>
> 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] Forcing OCamlbuild to compile a file before another

[Dario Teixeira]

Hi,

Still on the subject of getting module aliases and -no-alias-deps to 
work
with OASIS and OCamlbuild: I've created a repo on Github for Libfoobar 
[1],
the dummy example I've been using to test and play with this problem.

As you can see, I've opted to postprocess the output of OCamldep outside
the OCamlbuild plugin.  Essentially, I set the Options.ocamldep to call
myocamldep.ml, an OCaml script that serves as frontend to OCamldep and
does the actual postprocessing.

Note that there is project-specific knowledge in myocamldep.ml: there is 
a
dictionary 'dict' mapping between the module alias files (foo.ml and 
bar.ml)
and the aliases declared in each one.  This is the same information that
should be contained in an mlalias file.  In addition, the script makes 
some
assumptions regarding the naming of modules.  Though obviously this 
solution
is far from optimal, this being just a stop-gap measure it will do for 
now.

I've come across a snag which puts some doubt on the hope that this 
could
all be implementable without touching OCamldep itself.  Consider the 
Bar_a
module.  It should depend on Bar, Foo, and Foo_a.  However, OCamldep 
reports
its dependencies as only Bar and Foo.  The missing dependency on Foo.A 
is not
considered, which of course makes sense, but it's not what I was hoping 
for!

Kind regards,
Dario Teixeira

[1] https://github.com/darioteixeira/libfoobar

Re: [Caml-list] Forcing OCamlbuild to compile a file before another

[Gabriel Scherer]

I don't expect touching OCamldep to be very difficult. I'd be glad to
offer the time to provide a patch for the -paths option; ocamldep is a
small codebase and I don't expect much reluctance from the maintainers
to add a new feature (the code should be simple, and not affect
existing behaviors). That may require that you wait for the next
release in a few months; if you really needed to, you can probably
hack a simple external tool with the same feature today using the
compiler-libs.

On Fri, Feb 6, 2015 at 6:01 PM, Dario Teixeira
<dario.teixeira@nleyten.com> wrote:
> Hi,
>
> Still on the subject of getting module aliases and -no-alias-deps to work
> with OASIS and OCamlbuild: I've created a repo on Github for Libfoobar [1],
> the dummy example I've been using to test and play with this problem.
>
> As you can see, I've opted to postprocess the output of OCamldep outside
> the OCamlbuild plugin.  Essentially, I set the Options.ocamldep to call
> myocamldep.ml, an OCaml script that serves as frontend to OCamldep and
> does the actual postprocessing.
>
> Note that there is project-specific knowledge in myocamldep.ml: there is a
> dictionary 'dict' mapping between the module alias files (foo.ml and bar.ml)
> and the aliases declared in each one.  This is the same information that
> should be contained in an mlalias file.  In addition, the script makes some
> assumptions regarding the naming of modules.  Though obviously this solution
> is far from optimal, this being just a stop-gap measure it will do for now.
>
> I've come across a snag which puts some doubt on the hope that this could
> all be implementable without touching OCamldep itself.  Consider the Bar_a
> module.  It should depend on Bar, Foo, and Foo_a.  However, OCamldep reports
> its dependencies as only Bar and Foo.  The missing dependency on Foo.A is
> not
> considered, which of course makes sense, but it's not what I was hoping for!
>
> Kind regards,
> Dario Teixeira
>
> [1] https://github.com/darioteixeira/libfoobar
>
>
>
> --
> 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] Forcing OCamlbuild to compile a file before another

[Dario Teixeira]

Hi,

> I don't expect touching OCamldep to be very difficult. I'd be glad to
> offer the time to provide a patch for the -paths option; ocamldep is a
> small codebase and I don't expect much reluctance from the maintainers
> to add a new feature (the code should be simple, and not affect
> existing behaviors). That may require that you wait for the next
> release in a few months; if you really needed to, you can probably
> hack a simple external tool with the same feature today using the
> compiler-libs.

Thanks Gabriel: your work would be much appreciated, and I would be glad
to test it both in dummy examples and in a real library (namely 
Lambdoc).
As for the timing, it won't be a problem for me to wait for 4.03 before
making a 1.0-final release of Lambdoc, particularly if the compiler team
sticks to the recent pattern of gifting the community with a summer 
release.
Moreover, it wouldn't surprise me if some more edge cases are found in 
the
meantime...

Best regards,
Dario Teixeira

Re: [Caml-list] Forcing OCamlbuild to compile a file before another

[Gabriel Scherer]

Here is a preliminary patch to implement the [ocamldep -paths] option.
  https://github.com/ocaml/ocaml/pull/146

I would like to experiment with the use of the option from ocamlbuild
itself (or hear back from someone's experiments) to make sure the
feature is actually useful. Unfortunately I won't have time to do much
myself in the next two weeks, so that would not be before March.

On Fri, Feb 6, 2015 at 7:58 PM, Dario Teixeira
<dario.teixeira@nleyten.com> wrote:
> Hi,
>
>> I don't expect touching OCamldep to be very difficult. I'd be glad to
>> offer the time to provide a patch for the -paths option; ocamldep is a
>> small codebase and I don't expect much reluctance from the maintainers
>> to add a new feature (the code should be simple, and not affect
>> existing behaviors). That may require that you wait for the next
>> release in a few months; if you really needed to, you can probably
>> hack a simple external tool with the same feature today using the
>> compiler-libs.
>
>
> Thanks Gabriel: your work would be much appreciated, and I would be glad
> to test it both in dummy examples and in a real library (namely Lambdoc).
> As for the timing, it won't be a problem for me to wait for 4.03 before
> making a 1.0-final release of Lambdoc, particularly if the compiler team
> sticks to the recent pattern of gifting the community with a summer release.
> Moreover, it wouldn't surprise me if some more edge cases are found in the
> meantime...
>
> Best 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] Forcing OCamlbuild to compile a file before another

[Dario Teixeira]

Hi,

> Here is a preliminary patch to implement the [ocamldep -paths] option.
>   https://github.com/ocaml/ocaml/pull/146
> 
> I would like to experiment with the use of the option from ocamlbuild
> itself (or hear back from someone's experiments) to make sure the
> feature is actually useful. Unfortunately I won't have time to do much
> myself in the next two weeks, so that would not be before March.

Thanks Gabriel, I'm looking forward to trying this out.  One little snag
though: even after an update, the compiler switch for 4.03.0+pr146 does
not show up in OPAM.  Is it just a matter of time until the automation
makes it available, or does someone have to flip a switch first?

Kind regards,
Dario Teixeira

Re: [Caml-list] Forcing OCamlbuild to compile a file before another

[Gabriel Scherer]

It seems to be due to an issue with the patch (which breaks something
in ocamldoc), I'll fix it.

(If you don't mind using github (if you do, I can create a mantis
issue instead), we could use it for discussing this specific patch or
details of the `ocamldep -paths` feature. I'm not sure everyone on the
caml-list is interested.)

On Sun, Feb 15, 2015 at 2:55 PM, Dario Teixeira
<dario.teixeira@nleyten.com> wrote:
> Hi,
>
>> Here is a preliminary patch to implement the [ocamldep -paths] option.
>>   https://github.com/ocaml/ocaml/pull/146
>>
>> I would like to experiment with the use of the option from ocamlbuild
>> itself (or hear back from someone's experiments) to make sure the
>> feature is actually useful. Unfortunately I won't have time to do much
>> myself in the next two weeks, so that would not be before March.
>
>
> Thanks Gabriel, I'm looking forward to trying this out.  One little snag
> though: even after an update, the compiler switch for 4.03.0+pr146 does
> not show up in OPAM.  Is it just a matter of time until the automation
> makes it available, or does someone have to flip a switch first?
>
> 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