Hi, 2012/3/8 Daniel Bünzli <daniel.buen...@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. >
I think you need to use the function "X.foo" to cause the evaluation of toplevel statements. But it is something that need to be checked. > > 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 ? > I don't think I'll be able to integrate the Object section in 0.3. I am really planning to release it soon. I just had a quick look at your git repository and I don't think there will be a difference for user if it is a .cma (as long as they use ocamlfind). >> 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). > That the parsing time because the file is big. I know this issue and will try to improve that in the future. I think a 50% down size is possible, that will bring this time to 250ms. Although, I don't think that even for development env a 500ms delay is that big... I doubt to be able to reduce to ~0s. >> > 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. > Never try autoconf ;-) >> 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. > I suppose you where talking about "make clean", I read too fast, this is a different issue (ocamlfind remove), which is more a packaging question (i.e. to the odb/GODI level). >> 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. > OK, so first of all you are talking about the odb/GODI/oasis-db level. OASIS itself is not meant to handle that directly. There will be a plugin "oasis-db" that will allow you to do "oasis install xmlm" and "oasis uninstalll xmlm" and fetch the source from http://oasis.ocamlcore.org but this is the future and this won't be the core oasis system. You can have a look at odb that allow you to already do that after having uploaded your package to http://oasis.ocamlcore.org. Concerning the ocamlfind install + documentation. I understand you but it is technically not feasible right now (AFAIK). Simple fact: ocamlfind cannot install files in subdirectories. >> 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. > You understand well, I agree on the fact that lowercase is probably better. The solution you describe is also the one I will use. For a Linux guy, this is however not obvious (case insensitive filesystem is quite uncommon on Linux). Cheers Sylvain -- 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
