How does obuild compile dependencies?

[jordwalke]

I wrote CommonML because I wanted a way to automatically namespace based on dependencies, instead of by file path.
https://github.com/jordwalke/commonml

Can obuild do something similar? So if MyProject has utils.ml and YourProject has utils.ml, any source file in MyProject can access YourProject.utils automatically.

CommonML automatically tracks dependencies across projects and recompiles any changes to your dependent projects. It does this by assuming your dependency source code is installed in node_modules. Basically, I really like the sound of obuild and I might be able to just replace CommonML and point people to obuild if it can automatically build dependent projects (for some customizable definition of dependent - in my case, it means something inside the local ./node_modules directory).

[jeromemaloberti]

I'm not sure I understand what you mean by "dependent project". If you mean opam project (external and compiled) then no, if you mean a subdirectory in a large source tree, then yes.
Obuild is like oasis, you define libraries and executable(s) that are dependent and obuild will track which ones requires to be recompiled.
So if you have /node_modules/MyProject library and /node_modules/YourProject library, any modified source in any of them will trigger the recompilation of the module and the linking of the library and all library or executable depending on this library.
Does it answer your question ?

[jordwalke]

Yes, it does. For CommonML, dependent projects happen to be installed in a subdirectory of the main project root - although at a strange location:

`./node_modules/DependencyA/src/util.ml`

Here's what CommonML does, and I'd love it if obuild could accomplish the same: When my root project (that depends on it) has source files such as:

./src/util.ml

I need util.ml to see the "dependent project"s module as DependencyA.Util.

How can I achieve this convention with obuild? If it's relatively easy, I'd much rather completely abandon CommonML and point people to this project, which likely does a much better job of maintaining absolute minimal rebuilds (and in parallel) (hoping we can get module aliases instead of packs).

CommonML just builds projects in a similar way as obuild packs, but knows to namespace based on what is in node_modules.

One other difference (which isn't critical, but would be nice to unify on) is how CommonML namespaces things within a project (not from the "dependencies" installed to node_modules).

For example if you have:

    # "This" root project's source files.
    ./src/util.ml
    ./src/main.ml
    ./src/someHelpers/helper.ml

    # All of "this" project's dependencies' source are installed into `node_modules`.
    ./node_modules/DependencyA/src/main.ml
    ./node_modules/DependencyB/src/main.ml

     # But then all of *their* dependencies are installed into *their* `node_modules`
    ./node_modules/DependencyA/node_modules/DependencyAA/src/someUtils/foo.ml

1. Any file within my project's src/ directory can see any other module (without the java-esque directory packing structure). src/main.ml can see both Util.someVal and Helper.helperVal - without having to say SomeHelpers.Helper.someVal.
2. Anything in my "this" top project's src directory can see it's immediate but not transitive dependencies. For example ./src/main.ml sees DependencyA.main.someVal and DependencyB.main.someVal, but cannot see DependencyAA.Foo.someVal because it is not an immediate dependency.
3. However, DependencyA's main.ml can see DependencyAA.Foo.someVal.

It makes sense that you should only be able to see the immediately modeled dependencies, which is (in CommonML, encoded by the file system structure) (I didn't make the file system structure up, that's part of the spec for package.json (wildly popular package spec)).

[jordwalke]

The convention I chose for any module inside your project's src directory being able to see any other file (without additional namespace) was gotten from our internal development practices for module scoping at Facebook which seriously helps when performing large refactors on directory structures (you don't have to go change all the users of a module just because you change its location in the file system). For additional namespacing, the larger grained dependencies (anything that appears within node_modules) work well.

I understand if this doesn't work for you and you don't agree, but maybe obuild could allow you to customize exactly how you see your "dependencies" based on file structure, and how your internal directory structure does (or doesn't) map to additional namespacing within a project.

The real power of build systems like this is when you can start getting momentum around something that becomes common, and I'd gladly retire CommonML if we could accomplish much of the same with obuild.
(Note, if obuild can do what I'm suggesting with node_modules then it becomes fully capable of building any code hosted on npm - one of the most popular package managers for client side code).