API improvements - Githubissues

samoht / assemblage

A collection of tools to manage the configuration of OCaml projects

54 stars 4 forks source link

API improvements #46

Closed dbuenzli closed 10 years ago

dbuenzli commented 10 years ago

I noticed we had different ocp-indent configurations I thus added an .ocp-indent file, feel free to change it to what you see fit.

I added the File and Dir components (their implementation may not be correct, I'm not sure I fully understand yet all the base functions of Component and there's no translation in the Makefile).

But File may already be deprecated, I didn't look into Gen yet, but I have the impression that File is just a special case of Gen no ? So if we refactor Gen a little bit and make it more general we may express File using it (and maybe define an Assemblage.file as a shortcut). It's a good idea to try to keep the number components low, what do you think ?

samoht commented 10 years ago

It's a good idea to try to keep the number components low, what do you think ?

Adding a new component usually means adding some specific logics to build it into the builder. So yes, let's try to keep it small. It's maybe better to define specific functions which produce more generic components (so yes, val file: ... ['Gen of gen] seems fine).

dbuenzli commented 10 years ago

Ok then here are a few more questions:

Do you think it would also be workable to use Gen for the yet to be defined Doc component ?
I think Pkg should be used for three things 1) ocaml package 2) ocaml pp package, 3) c package (pkg-config interaction). I think it's no problem to use the same pkg type for the three. But do you think we really need a tag for each of these ? we could just have the tag in the pkg type, rather than explicit in the component type.

samoht commented 10 years ago

Well, actually if we really want to, I think we can almost project everything to something similar to Gen: for every component, you need to resolve the flags and pass them to a given tool. So as for the other bits, we could have a list of well defined component and on Other of <truc> (instead of Gen of gen).

Regarding the pkg_pp and pkg: yes you are right, it will simplify the API. The only thing to keep in mind is that pkg and pkg_pp don't have the same behavior in term of dependencies: for instance, when you want to create a library, you don't want to link with the libraries used by the pre-propressors (see the mess in _oasis to handle this: https://github.com/mirage/irmin/issues/23) (so in that case you don't want to traverse the graph edges which leads to a *_pp component).

samoht commented 10 years ago

Regarding the phase, I think it's actually better to have simply a Pp element: I'm sure we can use available to specify that a pre-preprocessor is not available in native mode.