Le vendredi, 9 mars 2012 à 20:11, Sylvain Le Gall a écrit :
> > > > Document "reference" > > Title: "Xmlm's documentation and module reference" > > Format: html > > Index: Xmlm.html > > Install: true > > DataFiles: doc/*.html, doc/*.css > > > > Document "distribution" > > Title: "Xmlm's distribution information files" > > Install: true > > DataFiles: README CHANGES > > > > Maybe a kind of enumerated Kind: field could give more information about > > the nature of the documents. That said, oasis still seems to be a little > > bit schizophrenic about installation: on one hand it shouldn't install, on > > the other hand it seems to offer fields to perform installation duties. > > I am probably off-topic, because I don't understand by what you mean > by "on one hand it shouldn't install, on the other hand it seems to > offer fields to perform installation duties." ? I was meaning in general. If oasis is supposed to be descriptive (in the sense here you have an executable, here you have a library, here you have documentation), why does it have a field like InstallDir for documents ? Why do we have something like XCustomInstall: cp XYZ; I mean understand why we have it, but shouldn't its usage be discouraged ? Now the Document sections I wrote above don't do anything for now but it seems to me that 1) It has the info for a potential downstream packager e.g. cp `oasis query Doc(reference)` $WHEREWEPUTTHATINOURDISTRIB 2) It has the info for the thing I choose to manage the oasis -install I hope that one day, that 2) will be able to its thing and push it at the right place (being it inside sitelib or not !). Isn't that a better approach than using XCustomInstall or InstallDir ? Should I do it differently ? Maybe the only thing that is missing in an agreement like you have for SourceRepository: this, head. to better caracterize the actual bits of documentation that are being described (b.t.w I added a Document samples with DataFiles:examples/*.ml) > But maybe what you miss here, > is that it is meant to build documentation. Yes, if eventually there's a system that is able to integerates these odocl why not. For now I don't see any advantage and I prefer to distribute them statically. One reason is that since all my documentation is in inside the .mlis I think its nice if someone just want to have a look at the docs that he doesn't need to build anything (e.g. if the lib has many deps). Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
