When the root is not the cwd, print a relative path for the "Entering
..." line rather than an absolute one.
Signed-off-by: Jeremie Dimino <jdimino@janestreet.com>
- remove hard-coded knowledge of ocaml-migrate-parsetree and ppx_driver
- get the exact driver parameters directly from the driver itself
Signed-off-by: Jeremie Dimino <jdimino@janestreet.com>
They are almost never used and they complicate the language. The
parsing of jbuild files in unchanged.
Signed-off-by: Jeremie Dimino <jdimino@janestreet.com>
The motivation for this change is implement the --build-dir feature. This
feature lets us control the build directory which previously always defaulted to
_build. To accomplish this, Path.t had to be modified to be:
External of External.t | In_source_tree of Local.t | In_build_dir of Local.t
To represent the 3 kinds of paths dune is dealing with. The In_build_dir
constructor in particular, is relative to Path.root or some external path.
A few other refactorings had to be done to support this transition:
* The workspace is now "settable". This means that we no longer have to pass it
explicitly when converting local to absolute paths.
* Path.is_local no longer makes sense and is renamed to Path.is_managed.
Roughly, is_managed identifies paths in the build and source directories.
* Path.absoulte has been renamed of_filename_relative_to_initial_cwd
* Path.Local.root is now "." (as opposed to "")
Signed-off-by: Rudi Grinberg <rudi.grinberg@gmail.com>
It now has to be the first line of the dune-project file and the
lexical conventions are stricter than the rest of the syntax.
This will allow making changes to the lexical conventions of the
language in the future.
Signed-off-by: Jeremie Dimino <jdimino@janestreet.com>
Replace the current generated parser by an ocamllex lexer + a simple
parser.
The new code is:
- much simpler and smaller
- shouldn't cause ocamlopt to stack overflow anymore on BSD systems
- slightly slower but not that much
Signed-off-by: Jeremie Dimino <jdimino@janestreet.com>
As `Sys.readdir`, it returns entries in an nondeterministic order.
This can cause problems if caller relies on the list being sorted.
See #820.
Signed-off-by: Etienne Millon <etienne@cryptosense.com>
When a symlink loop is detected, the following message is printed:
> Path X has already been scanned. Cannot scan it again through symlink Y
However, the actual symlink that is displayed depends on the order in
with `readdir` outputs the contents (which depends on FS internals).
This sorts the directory list so that the message is deterministic.
It can be tested by adding for example a `List.rev` call after
`Path.readdir`: the affected version will return a different version in
the `github764` test.
Signed-off-by: Etienne Millon <etienne@cryptosense.com>
Rudi Grinberg
Jérémie Dimino
Jeremie Dimino
Etienne Millon