Dependencies, sort out the mess

samoht / assemblage

A collection of tools to manage the configuration of OCaml projects

54 stars 4 forks source link

Dependencies, sort out the mess #38

Closed dbuenzli closed 10 years ago

dbuenzli commented 10 years ago

Easy to say.

samoht commented 10 years ago

What I have in mind currently (subject to change, we need to see how this works in practice):

we should limit the number of places where it is possible to set/add dependencies. Ideally, only when (i) creating compilation units and (ii) applying ocamldep to get internal dependencies.
this also means that we should re-thing a little bit how and when we call ocamldep: currently it is only at the configuration step, which means we can't have automatic dependency discovering for auto-generated code, or when you have internal pre-processors.
yes it is a mess -- would be great to have better support for computing dependencies in compiler-libs.

samoht commented 10 years ago

This also means that we should be able (and try) to remove most of the mutable fields in as_project.ml. This does not feel very good to need this and it is not easy to explain in the doc and diagnose when there is a problem.

dbuenzli commented 10 years ago

Actually I'm currently flagging the places where I see mutation with FIXMEs I want to get rid of mutation it feels very suspicious. (I'm normalizing components a bit, everyone should get an available argument #32 and a flags argument, I'll talk to you about this this afternoon.)

dbuenzli commented 10 years ago

For container components (pp, lib, bin, dir) I think it's still necessary to have an explicit list of their components (rather than trying to sort out from their direct deps). So here's how I see things, each component has a ?deps:component list argument for specifying dependencies. Container components have an additional component list unnamed argument.

samoht commented 10 years ago

Ok for the containers. But I'm still unsure about the named deps argument: each component has a name and a list of dependencies, it is a bit verbose to have to specify ~deps everytime.

dbuenzli commented 10 years ago

Mmmh I think it will be all right. I want to have it named so that the distinction is clear for container components between deps and its elements (otherwise I would also go for nameless). But then since I want regularity I want it named everywhere. Besides having it a named argument will allow to kill pointless [] when there are no deps.

N.B. the decision about being explicit about containers contents is just to avoid having the situation where for some reason you'd need to depend on a component and it would be included but you actually don't want it to be included. Don't know if this could happen in the realworld but if it once happens to you then you are in big trouble and I prefer troubleless systems.

samoht commented 10 years ago

ok feel free to do it then.