Re: [Caml-list] Re: oasis packaging questions

["Daniel Bünzli" <daniel.buenzli@erratique.ch>]

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