* Change jbuilder to load rules lazily
Rules are now loaded on a per directory basis as needed. This speed up
the start up time on large workspaces.
Does various refactoring as well.
* Simplify the handling of META files
We no longer generate a META.foo.from-jbuilder file. Nobody is using
this feature and it's making the new code more complicated.
* Let variables say whether they are Concat or Split
To concatenate the contents of a split variable, put it in a string:
"${var} ".
Fixes#300
See also https://github.com/janestreet/jbuilder/issues/408
* Issue a deprecation warning for ${!...}
* Treat ${CC}, ${<}, ${^} and ${read-lines:...} as split vars
* Change ${!^} into ${^} for this project jbuild rules
Add (copy_files <glob>) and (copy_files# <glob>) stanzas. These
stanzas setup rules for copying files from a sub-directory to the
current directory.
This provides a reasonable way to support multi-directory
library/executables in jbuilder.
Warn when a file is both present in the source tree and generated by
a rule. Before, jbuilder would silently ignore the rule. One now has
to add a field `(fallback)` to custom rules to keep the current
behavior.
Add a utop subcommand that build and execute a utop where all the libraries defined in the current directory are immediately available for interactive use.
* Allow digits in library/module names
Also include the malformed module name in the error message so it's more clear what it's complaining about.
* Update jbuild.ml
The code to support it is starting to become increasingly complicated
and the number of problem found is a bit alarming.
We'll reinclude it later after a bit more testing and hopefully some
simplifications.
The dependencies on library artifacts are now properly setup to point
to the files in _build/install/...
Moreorver, private interfaces are now only visible inside the library
itself and are only allowed for private libraries. When a project
defines multiple packages, this ensures that the visibility when all
packages are built simultaneously and when they are installed one by
one.
We can relax these restrictions later with a bit more work and a clear
definition of where private modules should be visible.
Add a field "public_interfaces" to library stanza listing which modules are public.
Private modules won't be accessible outside the scope where the library is defined.
While analysing packages using jbuilder, I found that some packages
use ${ROOT} to refer to the root of the project. However, this doesn't
work as ${ROOT} depends on the workspace configuration.
Add ${SCOPE_ROOT} to make this easier for projects with a lot of
nested sub-directories.
Currently (foreach ...) is too general and variables can be used
anywhere inside S-expressions.
We need to sort out how we are going to handle meta-programming first
as this might impact how we implement (foreach ...).
In any case, it's better not to have it in 1.0.0.