Merge: Love contrib
authorJean Privat <jean@pryen.org>
Mon, 8 Jun 2015 10:05:00 +0000 (06:05 -0400)
committerJean Privat <jean@pryen.org>
Mon, 8 Jun 2015 10:05:00 +0000 (06:05 -0400)
commitd52cb8ef4dd8aae4c84d3cae78bfe1bf95815ef0
tree7b228431a398099b7b9c2cf991a70d8ea0c560e7
parentd77539e67599b049607518b54210d468bb685d6c
parent3bb033007c2e1770dbd5797fd83380d1efb6316b
Merge: Love contrib

One day, a package manager will simplify the installation and the maintenance of third-party projects, libraries and programs in Nit, so that `import foo` will import the project `foo` if installed.

Noways, `contrib` is used as a placeholder for some independent projects that are not mainly a library (or borderline). However, the nature of the Nit language, especially the refinement of class blurry the difference between libraries and programs and make it conceivable to extends an existing program by refining it (or just reuse its base libraries).
However, `import foo` will not work if foo is in contrib, this issue has two current workarounds:

* the user use `-I` with some relative path location in the Makefile, that is not practical because it should be used on each tools thus broke basic manual commands (like nitc on the command line) and automatic commands (like vim+nitpick).
* the project just move itself to lib/ so that client can easily import it, but this is hard to conceptualize for some project like `nitiwiki`

The easy solution to solve this issue is to add `contrib` to the libpath.

Note: the loader still has to be rewritten to be less buggy, more simple and saner. cf #1250

Pull-Request: #1436
Reviewed-by: Romain Chanoir <chanoir.romain@courrier.uqam.ca>
Reviewed-by: Lucas Bajolet <r4pass@hotmail.com>
Reviewed-by: Alexandre Terrasa <alexandre@moz-code.org>