assemblage
assemblage copied to clipboard
samoht
[tools] create `ocamldsort-bin`
Would be nice to have a tool similar to ocamldsort but for binary objects. Could be useful to (i) build archive and (ii) build binaries. It's a bit painful to have to sort the file manually when we already compiled them in the right order.
What's the difference between ocamldsort and ocamldep -sort ? Also how do you envision that being used in the context of assemblage's build model ?
I think ocamldsort was created before the -sort option appeared in ocamldep, so yes it's a bit useless now.
In the context of assemblage, I was thinking of having something like:
<..>/foo.cma:
$(OCAMLC) `$(OCAMLDSORT) bar.cmo toto.cmo` -o <..>/foo.cma
Both the order of elements and the graph of dependency is "dynamic" and can't be expressed with an applicative functor (I think) so we need some localised and well-defined work-arounds: the .d file to inject dependencies from ocamldep is one of them, the other one being ocamldsort-bin or something similar.
Both the order of elements and the graph of dependency is "dynamic" and can't be expressed with an applicative functor (I think) so we need some localised and well-defined work-arounds: the .d file to inject dependencies from ocamldep is one of them, the other one being ocamldsort-bin or something similar.
Of course this won't fit in the build system model exposed by assemblage. Related to #75, #144, #135. I think it would be better not to think in terms of the Makefile backends which is anyway not able to express this without resorting to inefficient hacks and build strategy.
In any case I don't see why this should act at the level of binary cmos (and hence the need for that ocamldsort-bin thing) since determining this on the sources should be sufficient. My idea was more that this should happen at setup time and be expressed as a (private) configuration key. Changes to that configuration key should be detectable (basically, the key depends on all the sources involved, that duty may be left to backends) and should automatically retrigger a setup.
In other words rather than change the build system model I'm trying to find an interface between the build system model dependency model and the configuration dependency model (whose concrete implementation may be left to backends). This is related to #145, tweaking configuration keys (in that case the sorted list of sources) should retrigger minimal rebuilds. In this model the sorted list of sources would retrigger the whole definition of the build system but if we have a good serialized representation of its configuration on disk we could aim for minimal rebuilds.
In any case I don't see why this should act at the level of binary cmos (and hence the need for that ocamldsort-bin thing) since determining this on the sources should be sufficient. My idea was more that this should happen at setup time and be expressed as a (private) configuration key. Changes to that configuration key should be detectable (basically, the key depends on all the sources involved, that duty may be left to backends) and should automatically retrigger a setup.
I understand your point. What I don't really like in that scheme is that we use ocamldep a lot: individually on each file, then on all files on the library again (but that information is already in the cmo!).
I understand your point. What I don't really like in that scheme is that we use ocamldep a lot: individually on each file, then on all files on the library again (but that information is already in the cmo!).
Why ? The work done one the sources should be enough: you can use it to statically generate both the dependencies of compilation actions (i.e. which cmis needs to be compiled before you can *.ml -> *.cmo) and the correct link order in the link action.
That being said if these things are in the cmo best would be to provide a patch to the compilers that stable sorts the cmos provided to the link option. (the sort must be stable because of toplevel side effect tricks)