caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Andre OLIVEIRA MARONEZE <andre.oliveira_maroneze@irisa.fr>
To: caml-list <caml-list@inria.fr>
Subject: [Caml-list] Order of includes in Ocamlbuild
Date: Tue, 11 Mar 2014 13:19:55 +0100	[thread overview]
Message-ID: <531EFF6B.8090800@irisa.fr> (raw)

I found a bug in one of my tools, which compiles using ocamlbuild, and I 
would like to avoid similar situations in the future.

This bug is caused by having duplicate .ml files with the same name in 
different directories, which are both included via -I on the command line.

An interesting aspect is that the bug is not trivial to reproduce, 
because the order seen by ocamlbuild depends on the order in which the 
directory nodes were created, not on their names.

For instance, consider the following files, each containing a single 
line of code:

a1/a.ml : let f = 1

a2/a.ml : let g = 1

main.ml : let _ = A.f

File main.ml is the main file, and both subdirectories a1 and a2 contain 
a file with the same name, but each defines a different symbol.
In my case, I hadn't noticed that a duplicate name existed, and I 
included both directories when running ocamlbuild:

ocamlbuild -I a1,a2 main.native

Note that the order of the includes in the command line is irrelevant to 
ocamlbuild; it chooses its own include order, which depends mainly on 
which subdirectory was created first.
In some cases, ocamlbuild will include a1 before a2 and it will work, in 
other cases it will include a2 before a1 and fail ("Unbound value A.f").

By renaming directories (mv a1 tmp; mv a2 a1; mv tmp a2), or copying the 
directory structure to another disk partition, it is possible to invert 
the order seen by ocamlbuild and obtain surprising results.

I have two questions concerning this behavior:

1) Is there a way to ask ocamlbuild to detect this dangerous situation 
(duplicate file names in included directories) and warn the user?

2) Is there a way to force the include order to depend on directory 
*names*, via the command line or some other mechanism? In case item 1 is 
not feasible, this would at least ensure stability once a working 
include order is found.


Regards,
André

                 reply	other threads:[~2014-03-11 12:19 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=531EFF6B.8090800@irisa.fr \
    --to=andre.oliveira_maroneze@irisa.fr \
    --cc=caml-list@inria.fr \
    /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;
as well as URLs for NNTP newsgroup(s).