From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA12640; Wed, 14 Apr 2004 09:51:30 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA12125 for ; Wed, 14 Apr 2004 09:51:29 +0200 (MET DST) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i3E7pSYM011108 for ; Wed, 14 Apr 2004 09:51:28 +0200 Received: from warp (lns-th2-5f-81-56-197-80.adsl.proxad.net [81.56.197.80]) by postfix4-1.free.fr (Postfix) with SMTP id 5DA7ADC436; Wed, 14 Apr 2004 09:51:27 +0200 (CEST) Message-ID: <005e01c421f5$2dd45210$ef01a8c0@warp> From: "Nicolas Cannasse" To: "Brandon J. Van Every" , References: Subject: Re: [Caml-list] Re: GODI vs. Ocamake Date: Wed, 14 Apr 2004 09:50:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; cannasse:01 warplayer:01 caml-list:01 ocamake:01 python:01 spawned:01 ocamake:01 jacques:01 ocamlc:01 ocamlopt:01 ocamldep:01 unixes:01 mingw:01 cygwin:01 autoconf:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 312 > > Which creates another problem: GODI is based on C tools and BSD > > makefiles. I'm not sure this is the favorite kind of things ocaml > > programmers would maintain. > > An OCaml-centric packaging tool should be written in OCaml. Nobody's > switching to OCaml out of their love for C and C++! If that means GODI > is unsuitable to task, that is unfortunate but reality is reality. > Other languages such as Python and Java have spawned their own build > tools. There's a lot more to the world than Make. > > So how is OCamake? Is it not the obvious place to begin? As Jacques Garrigue answered, OCamake have been designed as a compilation tool, and is actually well suited for the Windows world since it doesn't rely on any 3rd party tools (apart from ocaml official distribution ones : ocamlc, ocamlopt and ocamldep) - it still work very well on Unixes. OCamake does not handle right now the building of C stubs, so it's only building pure-ocaml projects. But when we jump into the C side, you need a lot of extra configuration : - on windows things here are quite easy, but if you want to support MSVC + Mingw ( cygwin being optional IMHO ) it will takes time - unix world is very different from windows one, and is already filled with autoconf like tools that are checking a bunch of things in order to be able to compile The idea to enable OCamake to be highly configurable would be to have an "Ocamake Library" and then you'll write a file "makefile.ml" using that library in order to ease compilation and ensure you're writing a system-idependant makefile. Then you'll run ocamake (the tool) that will dynamicly load the makefile.ml in order to execute it. This - the system-idenpendant build of C stubs - will require quite a lot of work on Ocamake, and will require the library owners to write their makefile.ml compilation files. But in the end we would get a system-idependant build tool, that can later be used by a package manager in order to (re)compile a given package (the inter-package dependencies being handled at the package-manager level). Sadly, a lot of OCaml users are unixes ones that doesn't care at all about support of systems such as Windows or MacOs ( and they're sometimes true : when you're writing bindings to a unix-only library, who cares about your bindings being compilable on win32 ? ). Theses users are currently happy enough using autoconf / make since it doesn't require additionnal learning. GODI+findlib are made with the same thinking : they have not been designed to be SI since they're basicly (very) smart scripts relying on a lot of other unix tools. Other way of thinking is : what do we need in order to get binary-only distributions ? OCaml have a bytecode interpreter, so why we can't release libraries simply as a big CMA ( and some CMI's ). Answer : because the bytecode binary format is very strict, and not suited for this kind of usage (adding a function in the interface of a sub library needs to recompile all top librairies ). Maybe a more flexible bytecode format would help the community to build a good packaging tool without having to care about all theses compilation issues. (of course people would still need to compile for native code, but there is also here other ways such as providing a marchalled typed-AST as a binary "reading for input to ocamlopt"). Regards, Nicolas Cannasse www.motion-twin.com ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners