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

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

Le jeudi, 8 mars 2012 à 09:31, Sylvain Le Gall a écrit :
> The main change of .cmo -> .cma is that toplevel expression are only
> evaluated if you open the module.  


open, like the construct, I thought open was just about syntax ? You mean use or invoke a function ?
  
> This can be a problem if your .cmo are
> used in a plugin way (i.e. toplevel expression register the content of
> your library) and that you don't open it.


Nevertheless I think it's best for users to avoid the change. Is that Object section still due for 0.3 ? Otherwise is there a way to hack around ?  
  
> setup.ml will be enough for me ;-) But I am biased.

For distribution, I'm fine with that aswell. For developement setup.ml takes too much time to invoke (adds an overhead of 0.5s on my system).  

> > 4) I'm really not interested in oasis trying to generate my _tags and myocamlbuild.ml files. Is it ok to substitute my own or does setup.ml rely on these ?  
>  
> You can substitute your own. There should be no problem. Don't hesitate
> to open a feature request to explain the reason why and your solution. I
> don't promise it will be implemented, but it is worth understanding the
> reason.


First, all my modules don't need an myocamlbuild.ml, second since ocaml 3.12 it is now very easy to express findlib dependencies in _tags files. Third, I don't want to have to sweep through hundreds of generated lines of code (458 for myocamlbuild.ml) of useless configuration stuff when something goes wrong. Avoid bureaucracy at all costs.  
  
> We already discuss this CHANGES file stuff. I still didn't have the time
>  
> to work on that, but it is something that I want. In future version
> there should be something like that.
>  
> Use 'PostCleanCommand: rm XYZ'
>  
> DataFiles should do that.  

You may not have the tarball anymore when you want to uninstall things. That's certainly not a good approach.  
  
> Concerning installing this using ocamlfind, I
> am a little more skeptical. We use standard cp to install in
> /usr/share/doc. I don't know a lot of libraries that install their
> documentation in /usr/lib, probably because there are packaging rules
> against that.

  
I completely disagree with that. I think we already had this discussion. This monolithic view may be suitable for system level packaging system like debian. But I think its wrong to take this approach here. What I need as a developer, is an ocaml specific packaging system that is able to move much quicker than the system level package system and if possible in which you also may install more than one version of a library.  

The only clean approach that seems to work well when you want that is that every package installs in its own (versioned) prefix and symlink *if needed* in the regular system directories (see gnu stow, gobolinux or homebrew on osx). It also makes it *damn simple* to understand who installs what and to hack and understand the system when it breaks.

For me helping downstream packaging should not be the first goal of a system like oasis. From my developer's point of view downstream packaging is only usefull to help you to install the base (the language and the language specific package system) and then you should install what you need by using the language specific package system. Here again I think homebrew takes the right approach, they don't repackage any gem, python egg or perl module, they piggyback on the strength of these individual system and let the developers manage them letting them resort to homebrew only when they need dependencies that are outside the scope of the language specific system (C libraries etc.).  
  
So my proposal would be to let ocamlfind manage all that and agree on a few directories. I'm not proficient enough in ocamlfind but I guess it won't be able to support multiple versions. But at least if we can be sure that `ocamlfind remove <pkg>`, removes everything a package installed, documentation included it would be nice. For me it would be enough to stick the CHANGES, README right into ocamlfind's package directories.  

$SITELIB/<pkg>/META
$SITELIB/<pkg>/_oasis
$SITELIB/<pkg>/README
$SITELIB/<pkg>/CHANGES
$SITELIB/<pkg>/share/html/*.html  
$SITELIB/<pkg>/share/examples/
etc.

Having standard like this could also help efforts like typerex (or even ocamlfind) to know where to lookup for documentation data. Now oasis is the place to enforce such a standard.

> I realize that this no good. I probably should code a plugin Static, to
> have "Type: Static" and use the data you fill in Document section to
> install. This is not a long job.
>  
> Could you open a bug about that, so that it will remind me to do it ?

Here you have. https://forge.ocamlcore.org/tracker/index.php?func=detail&aid=1111&group_id=54&atid=291

> That is a bug. I have similar problem with the Pack: when generating
> _tags with capitalized module name. I installed ocaml on a mac yesterday
> to find the right solution. It will be shipped with oais 0.3.0~rc3. But
> this part of the bug is not extremly important, because on case
> sensitive FS, it will replace the capitalize module name by the right
> name. It is a runtime evaluation so no worries on this point.

Well I'm not sure I follow your explanation. Wild guessing I suspect you derive the file name from the Modules: key and just try different spellings until a Sys.file_exists returns true. But if you first try with a lowercase you'll always get a true on a case insensitive file system even if the actual file starts with an uppercase, and vice versa so the problem seems insoluble that way, I see no other solution than Sys.readdir the build directory and look for the correct spelling in there. Note it's a real problem if you want the tool to be a good unix citizen, for example diffing d1 and d2 with d1/a.ml and d2/A.ml, will report a.ml and A.ml as being different even if you are on a case insensitive file system. Btw. the standard still seems to have lowercased files module files (witness the whole ocaml system itself), in fact I thought this was mandated by the compilers (don't know were I got that), so in any case using lowercase first may be a better approximation.
  
Best,

Daniel