Skip to content

Latest commit

 

History

History
166 lines (114 loc) · 5.36 KB

ROADMAP.org

File metadata and controls

166 lines (114 loc) · 5.36 KB

This document describe the plan for the next releases of Jbuilder.

V1

CLI

Add a proper cmdliner based CLI. Jbuilder will include a copy of cmdliner to avoid the extra dependency.

  • 20/02/2017: This is now implemented thanks to Rudi Grinberg (#5)

Improve the man pages

Add a bit more documentation in the Man pages generated by cmdliner.

Documentation

Document the usage and design of Jbuilder.

  • 21/02/2017: There is now a manual, it still needs a bit more about CLI usage
  • 07/03/2017: Manual is complete

Stable jbuild types

Add a stable version of the jbuild format so that one can write (jbuild_version 1) inside jbuild files and be sure that they will work with future versions of jbuild.

  • 24/02/2017: implemented

Finding the project/workspace root

Currently jbuilder assumes that the root of the project/workspace is where it is started. Eventually this will be changed as follows:

  • if there is a jbuild-workspace in a parent directory, it marks the root;
  • if not found, look for a opam or package.opam file in parent directories;
  • if not found, look for a .git, .hg, … file in parent directories;
  • if not found, use the current directory as root.
  • 28/02/2017: Implemented

Generate .merlin files #1

  • 25/02/2017: Implemented by Richard Davison (#2)

Running tests with jbuilder #3

Allow to define tests with (alias ...) stanzas and add jbuilder runtest to run them.

  • 21/02/2017: Rudi Grinberg added support for aliases (#7)
  • 23/02/2017: Added a runtest subcommand

Implement package version support

Implement finding the version of a package, as described in the documentation.

  • 24/02/2017: Implemented

After V1

Cross-compilation

Everything needed for cross-compilation is implemented. One essentially need to add a function host_exe : Path.t -> Path.t inside build contexts to make it all work, as well as a way to define the build contexts. These could be defined inside jbuild-workspace as follows:

(context
 ((name   foo)
  (switch 4.04.0)))

(context
 ((name   foo+mingw)
  (switch 4.04.0+mingw)
  (host   foo)))

Topkg integration

It would be nice to integrate with topkg. Some of the features overlap, and for instance there doesn’t seem to be much point in using topkg to generate the .install or invoke jbuilder since jbuilder already handles that well. However, the other features available through the topkg command line tool would be good to have.

Jenga bridge

Implement a jenga plugin that can read the same jbuild files as Jbuilder. To do that we’ll use Jbuilder as a library.

odoc support

Support generating documentation with odoc.

Inline tests

Setup automatic support of inline tests and inline benchmarks.

Extend the action language

Currently in (action ...) fields, when not using bash the language is very limited. It would be nice to add more commands that would guarantee portability and avoid the quoting nightmare of bash.

FS commands should be straight foward to implement:

  • (copy <src> <dst>)
  • (mkdir <path>)
  • …

Redirections to/from files are simple as well.

We could also implements pipes ((pipe <command1> <command2> ...)) by using temporary files. Using proper pipes would complicate windows support and would make proper handling of -j hard. Using temporary files will be just fine.

User configuration file

Load a configuration file from ~/.config/jbuilder/config.sexp where the user can define preferences such as colors.

Code improvements

Delete the global variables in Clflags

Improve the Action.Unexpanded.t

String_with_vars.t should take a type parameter and we would have:

type variable =
  | Plain of string
  | Bin of string
  | Lib of string * string
  | ...
type user_action =  variable Action.Unexpanded.t

This would allow to report parsing errors immediately and at the right location.

Consolidate the S-expression parser

It doesn’t follow the specification given in the readme of parsexp. This need to be fixed.

Make Jbuild_plugin a library

Currently Jbuilder generates a wrapper script containing the source code of the Jbuild_plugin followed by the user script. While this method is trivial to implement, it is not great if users want to write libraries for jbuild plugins.

What we should do instead is create a proper jbuild_plugin library that is installed. This library should read a file containing the build context details generated by Jbuilder and passed as Sys.argv.(1).

We need to refactor things a bit to make this happen, in particular the library will propably need to know how to parse s-expression. We can create a jbuild_common library to put the parts that are common between jbuild_plugin and jbuilder.

Note that doc/jbuild is an OCaml script. To simplify the bootstrap, we should just convert it back to a static jbuild file.