Merge: New loader policy that features project.ini
authorJean Privat <jean@pryen.org>
Wed, 26 Aug 2015 18:27:03 +0000 (14:27 -0400)
committerJean Privat <jean@pryen.org>
Wed, 26 Aug 2015 18:27:03 +0000 (14:27 -0400)
commit5adfdf4d7e37e1d6dd1b4d2557ac780d46474955
tree8683843404a062209c476bc54ad43e2e3cce2fdd
parente315432751e8a1f057cdceff9a49654dcf9f62fc
parentb580baf1abffd8c95a17a2f007c7025a21ceec68
Merge: New loader policy that features project.ini

This introduce the new loader policy by adapting the existing loader.
The API it still as bad as before but the behavior is expected to be better. Close #1250

The changes impact two decisions made by the loader:

* how to find the project a module belongs to? ie get the root project of an arbitrary file.
* how to find a named module in a project? ie get (and load) the module named `foo` in a mproject object.

The new loader use a recursive directory search for both answers, whereas the older loader only looked at some specific paths.
By the way, the new code use `String::files` and `String::file_stat` (they where unneeded by the previous loader, life was simpler back then). The light FFI used by the bootstrap make this possible.

Here is a detail of the new policy:

* A project is a directory identified with a `project.ini` file.
  Only the existence of the `.ini` file matter, the content is not used yet.
* A group is just a sub-directory of a project; there is no more naming or structural convention (ie hack).
* A module either belongs to a project, or is a standalone module (also called singleton project). This one is not new.

To know the project a module belongs to, its directory is recursively searched up to the `/` directory.
If a project is found, then the module belongs to it.
If no project is found, then the module is a standalone module.

Note: to simplify the migration from the previous loader, a special file `projects.ini` (with a plural) in a directory indicates that sub-directories are projects, even without a `project.ini` file.
These files simplify the PR as only some `projects.ini` files are needed (eg `lib/projects.ini`)

To search for a module in a project, the named module is searched in the directory and subdirectories of the project.

This PR also expose some vocabulary for the end user. Maybe some terms could be improved before the PR is merged. Some propositions:

* rename `project` as `package` (so `package.ini` instead of `project.ini`). Might be non-POLA from people coming from a Java ecosystem.
* rename `group` as `directory`. With the new policy, groups are more transparent than ever and are only here for the programmer to group modules as he prefers.

Pull-Request: #1654
Reviewed-by: Lucas Bajolet <r4pass@hotmail.com>
Reviewed-by: Alexis Laferrière <alexis.laf@xymus.net>
Reviewed-by: Alexandre Terrasa <alexandre@moz-code.org>