ocamlbuild and automatic dependencies

ocamlbuild and automatic dependencies

[Joel Reymont]

ocamlbuild does handle "open Module" as well as detect usage of  
Module.xxx. It does not seem to detect "module X = Module" and then  
X.xxx when calculating dependencies.

Am I missing something?

In my particular case, I cannot open two modules because they contain  
type definitions of the same name.

	Thanks, Joel

--
http://wagerlabs.com/

Re: [Caml-list] ocamlbuild and automatic dependencies

[Nicolas Pouillard]

On 3/14/07, Joel Reymont <joelr1@gmail.com> wrote:
> ocamlbuild does handle "open Module" as well as detect usage of
> Module.xxx. It does not seem to detect "module X = Module" and then
> X.xxx when calculating dependencies.
>
> Am I missing something?
>

ocamlbuild runs ocamldep -module on your file so you can experiment by yourself.

In "module X = Module" ocamldep infer a dependency on Module that's all.

Since ocamldep can makes false positive (open A ;; open B ;;)
ocamlbuild do nasty things to get rid of that.

The drawback, is that sometimes ocamlbuild ignore silently some dependencies.
In that case run it with -verbose 1 and look at the _log file.

You will see:

Warning: Failed to build the module B requested by ocamldep

If you do think that's wrong to ignore it, then force it's construction:

ocamlbuild b.cmo

You will see why ocamlbuild ignores it.

Hope it helps,

Cheers,

-- 
Nicolas Pouillard

Re: [Caml-list] ocamlbuild and automatic dependencies

[Joel Reymont]

Nicolas,

On Mar 14, 2007, at 12:24 PM, Nicolas Pouillard wrote:

> ocamlbuild runs ocamldep -module on your file so you can experiment  
> by yourself.

generator.ml:

open Ninja
module E = Easy

ocamldep -modules generator.ml
generator.ml: Easy List Ninja String

ocamlbuild test.byte --
+ ocamlfind ocamlc -package ounit -linkpkg easy_code.cmo  
generator.cmo parser_util.cmo symtab.cmo easy_parser.cmo  
easy_lexer.cmo parser_test.cmo generator_test.cmo test.cmo -o test.byte
Error while linking generator.cmo: Reference to undefined global `Easy'

The warnings in the _log file are about OUnit which is an external  
library. There are no other warnings. Everything builds fine if I  
remove "module E = Easy" and replace all references to E.xxx with  
Easy.xxx.

	Thanks, Joel

--
http://wagerlabs.com/

Re: [Caml-list] ocamlbuild and automatic dependencies

[Nicolas Pouillard]

On 3/14/07, Joel Reymont <joelr1@gmail.com> wrote:
> Nicolas,
>
> On Mar 14, 2007, at 12:24 PM, Nicolas Pouillard wrote:
>
> > ocamlbuild runs ocamldep -module on your file so you can experiment
> > by yourself.
>
> generator.ml:
>
> open Ninja
> module E = Easy
>
> ocamldep -modules generator.ml
> generator.ml: Easy List Ninja String

That's correct

> ocamlbuild test.byte --
> + ocamlfind ocamlc -package ounit -linkpkg easy_code.cmo
> generator.cmo parser_util.cmo symtab.cmo easy_parser.cmo
> easy_lexer.cmo parser_test.cmo generator_test.cmo test.cmo -o test.byte
> Error while linking generator.cmo: Reference to undefined global `Easy'

That's strange easy.cmo is missing.

Can you try "ocamlbuild easy.byte" ?

> The warnings in the _log file are about OUnit which is an external
> library. There are no other warnings. Everything builds fine if I
> remove "module E = Easy" and replace all references to E.xxx with
> Easy.xxx.

That's strange since the only interaction is via ocamldep where the
output is located in _build/xxx.ml.depends


-- 
Nicolas Pouillard

Re: [Caml-list] ocamlbuild and automatic dependencies

[Joel Reymont]

On Mar 14, 2007, at 12:43 PM, Nicolas Pouillard wrote:

> That's strange easy.cmo is missing.

There's no easy.ml, only easy.mli. Does this change anything?

> Can you try "ocamlbuild easy.byte" ?

ocamlbuild easy.byte
Solver failed:
   Ocamlbuild cannot find or build easy.ml.  A file with such a name  
would usually be a source file.  I suspect you have given a wrong  
target name to Ocamlbuild.
Backtrace:
   - Failed to build the target easy.byte
       - Building easy.byte:
           - Building easy.cmo:
               - Failed to build all of these:
                   - Building easy.ml:
                       - Failed to build all of these:
                           - Building easy.mly
                           - Building easy.mll
                   - Building easy.ml:
                       - Failed to build all of these:
                           - Building easy.mly
                           - Building easy.mll
                   - Building easy.mlpack

--
http://wagerlabs.com/

Re: [Caml-list] ocamlbuild and automatic dependencies

[Nicolas Pouillard]

On 3/14/07, Joel Reymont <joelr1@gmail.com> wrote:
>
> On Mar 14, 2007, at 12:43 PM, Nicolas Pouillard wrote:
>
> > That's strange easy.cmo is missing.
>
> There's no easy.ml, only easy.mli. Does this change anything?
>

Yep that's all the difference. That's no more an ocamlbuild problem :)

$ cat foo.mli
type t = A | B
$ cat bar.ml
module F = Foo
type t = F.t

$ ocamlc -c foo.mli
$ ocamlc bar.ml
Error while linking bar.cmo: Reference to undefined global `Foo'

Perhaps a bug ?

-- 
Nicolas Pouillard

Re: [Caml-list] ocamlbuild and automatic dependencies

[skaller]

On Wed, 2007-03-14 at 14:11 +0100, Nicolas Pouillard wrote:

> > There's no easy.ml, only easy.mli. Does this change anything?

> Yep that's all the difference. That's no more an ocamlbuild problem :)

> $ cat foo.mli
> type t = A | B
> $ cat bar.ml
> module F = Foo
> type t = F.t
> 
> $ ocamlc -c foo.mli
> $ ocamlc bar.ml
> Error while linking bar.cmo: Reference to undefined global `Foo'
> 
> Perhaps a bug ?

It's a 'bug' in Ocaml:

skaller@rosella:/work/felix/svn/felix/felix/trunk$ cat bar.ml
type t = Foo.t

skaller@rosella:/work/felix/svn/felix/felix/trunk$ ocamlc bar.ml

That links fine -- why would you expect introducing
an alias to change the compilation requirements?



-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] ocamlbuild and automatic dependencies

[Alain Frisch]

skaller wrote:
> That links fine -- why would you expect introducing
> an alias to change the compilation requirements?

Just in case: there is no such thing as module aliasing in OCaml (for a
decent definition of aliasing). In particular, after writing "module A =
B", it is not always valid to replace occurrences of B with occurrences
of A.

-- Alain

Re: [Caml-list] ocamlbuild and automatic dependencies

[skaller]

On Wed, 2007-03-14 at 21:57 +0100, Alain Frisch wrote:
> skaller wrote:
> > That links fine -- why would you expect introducing
> > an alias to change the compilation requirements?
> 
> Just in case: there is no such thing as module aliasing in OCaml (for a
> decent definition of aliasing). In particular, after writing "module A =
> B", it is not always valid to replace occurrences of B with occurrences
> of A.

Hmm .. another weirdness of the module system. You say
"it is not always valid" .. so when is it valid?

I have to say after quite some time writing Ocaml I still
don't really understand modules. 

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] ocamlbuild and automatic dependencies

[Joel Reymont]

It appears that simply copying foo.mli into foo.ml should solve the  
issue.

I kind of hate having two identical files that I'll need to update.  
Do I have to get used to it?

	Thanks, Joel

On Mar 14, 2007, at 1:11 PM, Nicolas Pouillard wrote:

> $ cat foo.mli
> type t = A | B
> $ cat bar.ml
> module F = Foo
> type t = F.t
>
> $ ocamlc -c foo.mli
> $ ocamlc bar.ml
> Error while linking bar.cmo: Reference to undefined global `Foo'
>
> Perhaps a bug ?

--
http://wagerlabs.com/

Re: [Caml-list] ocamlbuild and automatic dependencies

[Daniel de Rauglaudre]

Hi,

> On Mar 14, 2007, at 1:11 PM, Nicolas Pouillard wrote:
> 
>module F = Foo

This means : "define a module named F whose *implementation* is the
implementation of Foo".

Therefore it is normal that at link time, the system asks for an
implementation of foo.

IMHO, it is not a bug.

-- 
Daniel de Rauglaudre
http://pauillac.inria.fr/~ddr/

Re: [Caml-list] ocamlbuild and automatic dependencies

[skaller]

On Fri, 2007-03-16 at 15:22 +0100, Daniel de Rauglaudre wrote:
> Hi,
> 
> > On Mar 14, 2007, at 1:11 PM, Nicolas Pouillard wrote:
> > 
> >module F = Foo
> 
> This means : "define a module named F whose *implementation* is the
> implementation of Foo".
> 
> Therefore it is normal that at link time, the system asks for an
> implementation of foo.
> 
> IMHO, it is not a bug.

No, just hard to understand without an explanation such as
the one you gave which is good, thanks!

So actually, this F is distinct from Foo, even though all the
members are the same. In particular, if Foo has an abstract type t,
is F.t the same type as Foo.t?

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] ocamlbuild and automatic dependencies

[Daniel de Rauglaudre]

Hi,

On Sat, Mar 17, 2007 at 11:18:26AM +1100, skaller wrote:

> So actually, this F is distinct from Foo, even though all the
> members are the same. In particular, if Foo has an abstract type t,
> is F.t the same type as Foo.t?

Yes. If you write "module F = Foo", you say : the interface and the
implementation of F are the same as the interface and the
implementation of Foo. Therefore F.t is the same type as Foo.t.

On the other hand, if you add a signature constraint, you can make
the types different :

   module Foo = struct type t = A end
   module F = (Foo : sig type t = A end)
   let f (x : F.t) = (x : Foo.t)
                      ^
   This expression has type F.t but is here used with type Foo.t

-- 
Daniel de Rauglaudre
http://pauillac.inria.fr/~ddr/

Re: [Caml-list] ocamlbuild and automatic dependencies

[Alain Frisch]

skaller wrote:
> So actually, this F is distinct from Foo, even though all the
> members are the same. In particular, if Foo has an abstract type t,
> is F.t the same type as Foo.t?

Yes, because the signature inferred for F keeps a sharing constraint
t = Foo.t. But if G is some functor with an abstract type s in the
result, then G(F).s and G(Foo).s are not equal (because there is no
sharing constraint between modules, such as F = Foo).

-- Alain

Modules for Dummies

[skaller]

On Sat, 2007-03-17 at 09:14 +0100, Alain Frisch wrote:

[changed the title to something more appropriate]

> skaller wrote:
> > So actually, this F is distinct from Foo, even though all the
> > members are the same. In particular, if Foo has an abstract type t,
> > is F.t the same type as Foo.t?
> 
> Yes, because the signature inferred for F keeps a sharing constraint
> t = Foo.t. But if G is some functor with an abstract type s in the
> result, then G(F).s and G(Foo).s are not equal (because there is no
> sharing constraint between modules, such as F = Foo).

Hmm .. this is quite hard to understand.
So let's consider:

module F = Foo
module G = Foo

then F.t and G.t are also the same type because they both
have an inferred sharing constraint t = Foo.t, but F, G,
and Foo are distinct modules. Perhaps I could also write:

module Foo = struct type t = int end
module F = struct type t constraint t = Foo.t val x = 1 end
module G = struct type t constraint t = Foo.t val y = 2 end

to get the same sharing? but clearly Foo, F, G are distinct.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] ocamlbuild and automatic dependencies

[Jacques Garrigue]

From: Joel Reymont <joelr1@gmail.com>

> It appears that simply copying foo.mli into foo.ml should solve the  
> issue.
> 
> I kind of hate having two identical files that I'll need to update.  
> Do I have to get used to it?
> 
> 	Thanks, Joel

But... you don't need foo.mli.
So having only foo.ml should be enough.
I know this may feel a bit strange, but in this case the essential
part is foo.ml.
Note that this is partly due to the fact foo.mli does not define a
module type, it just wraps some type definitions done in foo.ml.

An amusing alternative is to define a module type in foo.mli.

module type T = sig
  type t1 = ...
  type t2 = ...
  ...
end

Now you can define a module containing the types of Foo.T without any
implementation:

module rec FT : Foo.T = FT

Of course this only works if T contains only type definitions.

Cheers,

Jacques Garrigue