search

ocsigen / js_of_ocaml

Compiler from OCaml to Javascript.
http://ocsigen.org/js_of_ocaml/
Other
961 stars 188 forks source link

Consider to use OASIS #25

Closed kit-ty-kate closed 8 years ago

kit-ty-kate commented 11 years ago

Because, why not :)

dbuenzli commented 11 years ago

What does oasis bring you ? My personal experience is that it's just one slow, useless, layer of indirection.

kit-ty-kate commented 11 years ago

Like I said here: ocsigen/deriving#15, « For maintenance, readability and packaging purpose »

dbuenzli commented 11 years ago

Well these are just words in the air, no proper argumentation.

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.

Drup commented 11 years ago

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.

kit-ty-kate commented 11 years ago

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).

dbuenzli commented 11 years ago

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

dbuenzli commented 11 years ago

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

kit-ty-kate commented 11 years ago

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.

dbuenzli commented 11 years ago

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

hhugo commented 11 years ago

https://github.com/ocsigen/js_of_ocaml/pull/40