Closed kit-ty-kate closed 8 years ago
What does oasis bring you ? My personal experience is that it's just one slow, useless, layer of indirection.
Like I said here: ocsigen/deriving#15, « For maintenance, readability and packaging purpose »
Well these are just words in the air, no proper argumentation.
oasis
insulates you from your build system and when something breaks it's a pain to figure out what doesn't work (you've got to love looking into a hundred of loc of generated myocamlbuild.ml
/_tags
file). Reclaim your build system !oasis
and it's more something that gets in your way than helps you (e.g. the strong _oasis
versioning scheme, the bad error messages when something breaks, the insulation from your build system). opam
friendly workflow: add an opam
file at the toplevel of your repo. This will (1) allow you to specify your package metadata as you would do in oasis
(2) provide the actual file to use for opam packagers (3) as of opam
1.1 this file will be used to build your package if you opam pin
the repo. This allows you to pin a package whose build instructions may have change w.r.t. to the instructions present in the opam repository (pinning is very useful to ask people to test for fixes/and or prereleases). And if your build system is able to generate a precise .install
file of what it build you further liberate yourself from ocamlfind
for installing and removing the package and provide a good semantic specification of what should be installed by distribution packagers.At the moment we have in the ocaml world, the compilers, ocamlfind
, oasis
, opam
and a build system of your choice. This hydra is both painful and slow to work with. I'm a strong proponent that we should eventually get to a world were we have the compilers (i.e. they should swallow the notion of ocamlfind
package), opam (transparently manage the differences between build systems, swallow _oasis
) and a build system of your choice.
As much as I like your libraries and appreciate your usual intervention, this is just stupid. I shouldn't, because it's a big troll, but I will answer.
The current situation is an enormous pile of shitty makefile absolutely not aware of any packaging stuff, without metadata, without dynamic recalculation of the dependency graph (you realize that the .depend is commited ?!) and that one guy (may heaven save his soul, in all friendship) did one day and no one want to look at anymore. Oasis is better than that in every single aspect you can ever imagine.
What's your proposition ? Do a custom build system with some shell script do to the packaging ? It works for you because you're going to maintain your library yourself for a long time, it's not maintainable here because the guy who will do this will (obviously) not document it properly and someone else is going to try to modify it at some point. You can imagine what follows. Have an opam file for metadata ? And if you want do to a deb package, your doomed to do it by hand (as opposed to oasis2deb thingy).
Sorry for the aggressive tone, but your remark is really just trolling and that upset me a little. I don't think an helpful conversation can emerge from this so I'm not going to continue argue on the topic.
For more arguments, I'll say that multiples solutions (for build-system and packaging) are available. OASIS (+ ocamlbuild): the arguments against oasis are: a slow development, simple plugins (à la ocamlbuild) are not possible/simple. obuild is cool, but it's too young and it lakes a lot of plugin possibilities (beside, it's not the goal). ocp-build is also cool, but it also lakes some plugin possibilities and the camlp4 integration is (for what I've tested) somewhat a little poor (can evolves quickly in the future) The other are makefiles-like/scripts solutions without packaging possibilities. Sorry if I forgot to mention something.
For me, OASIS stay (IMHO and for the moment), the best
Note that I also like your libs but your custom build system is too shady and opam is definitively not a replacement for those tools (at least the packaging part).
What's your proposition ?
My proposition is that existing build systems should really look into integrating the notion of opam .install file to be able to describe them and generate them.
Have an opam file for metadata ? And if you want do to a deb package, your doomed to do it by hand (as opposed to oasis2deb thingy). And why not develop opam2deb ? What makes such a tool impossible to write ? opam's .install files are already able to express much more things to install than oasis is able to without the cumbersomeness and heavyness of oasis.
Sorry for the aggressive tone, but your remark is really just trolling and that upset me a little.
It's not trolling, it's friendly advice on a project that I follow.
This is a remark from someone who develops, documents, publishes and formally releases 12 OCaml packages and is going to publish more. From someone that committed and did genuinely try to use oasis and lost way too much time for very very little gain. From someone who saw that it would absolutely not scale for maintaining that growing collection of packages. From someone who has not time to lose with broken ideas, tools and layers of indirections.
Now do whatever you want to do with that.
Happy bureaucracy,
Daniel
Le mardi, 24 septembre 2013 à 14:58, Jacques-Pascal Deplaix a écrit :
Note that I also like your libs but your custom build system is too shady and opam is definitively not a replacement for those tools (at least the packaging part).
I don't have a custom build system I use ocamlbuild.
For packaging I have a single trivial shell script (https://github.com/dbuenzli/pkgopkg/blob/master/pkg/pkg-builder) to be included that helps me to generate an opam .install file with what is build by a single ocamlbuild invocation. You know what ? I find that much less shady, more trivial and easier to specify and understand than whatever oasis does behind the scene.
If you want to see how it works in practice.
See Uutf:
https://github.com/dbuenzli/uutf/blob/master/opam https://github.com/dbuenzli/uutf/blob/master/pkg/build
See Vg (optional dependencies):
https://github.com/dbuenzli/vg/blob/master/opam https://github.com/dbuenzli/vg/blob/master/pkg/build
See Webglue (complex example with dynamic plugins and where man page to install are generated by the tool to be build itself):
https://github.com/dbuenzli/webglue/blob/master/opam https://github.com/dbuenzli/webglue/blob/master/pkg/build
Of course it is my goal to eventually kill that shell script by a build system that is able to generate a proper .install file but for now given the bad state of build systems for ocaml I'll keep going on with that.
Daniel
I don't have a custom build system I use ocamlbuild.
Oh I didn't know. At least this is nice. :) The rest still shell scripts, and the META file is not generated (which is IMHO one of the good features of the three tools that I listed before).
Also, I agree that a thiner layer (or in certain cases no layer at all) between the build-system and the package system is great, but I think it can be improved with the current tools.
Le mardi, 24 septembre 2013 à 21:40, Jacques-Pascal Deplaix a écrit :
The rest still shell scripts, and the META file is not generated (which is IMHO one of the good features of the three tools that I listed before).
Well to be honest writing a META file is the least of my problems.
As for the fact of being a shell script, given it does what is needed in all my use cases and it's a 77 loc generic shell script, I let you compare that to the size of oasis which is a 17kloc OCaml project (without counting dependencies) written in an uncompact style oblivious of any of the OCaml programming guidelines (yeah I even considered contributing to oasis at a certain point but was repelled by the code) and that is not even able to describe what I'd like to do without still having to hack the generated _tags files manually and/or add shell scripts callbacks soups to invoke to generate things like man pages. Well, my choice is made.
I don't say the above script is what I want to live eternally with but it does show that in many cases very little is actually needed and can be described in a straightforward way. I'm almost sure that the above could be replaced, for example, by an appropriate ocambuild plugin or a small third party ocaml program reading from a particular description file, and generating your META along the way. But one thing I'm personally sure is that I don't want to deal with oasis anymore, ever, and that there are simpler ways out. YMMV.
Daniel
Because, why not :)