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 EAA00729; Sat, 17 Apr 2004 04:31:03 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id EAA32266 for ; Sat, 17 Apr 2004 04:31:00 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i3H2W1jq024180 for ; Sat, 17 Apr 2004 04:32:03 +0200 Received: from [192.168.1.200] (ppp117-65.lns1.syd2.internode.on.net [150.101.117.65]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i3H2UqZq005113; Sat, 17 Apr 2004 12:00:54 +0930 (CST) Subject: Re: [Caml-list] build tools - good vs. fast, both cheap From: skaller Reply-To: skaller@users.sourceforge.net To: William Lovas Cc: caml-list In-Reply-To: <20040416215308.GA21540@force.stwing.upenn.edu> References: <1082126288.20063.69.camel@pelican.wigram> <20040416215308.GA21540@force.stwing.upenn.edu> Content-Type: text/plain Message-Id: <1082169051.20063.449.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 17 Apr 2004 12:30:52 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 lovas:01 2004:99 owen:99 ocamldoc:01 interscript:01 spanish:99 plural:99 spanish:99 ocamldep:01 wrappers:01 swig:01 swig:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sat, 2004-04-17 at 07:53, William Lovas wrote: > On Sat, Apr 17, 2004 at 12:38:08AM +1000, skaller wrote: > This is essentially the goal of the GODIVA project (formerly GODOR) that > Owen Gunden and i are working on: We're grafting a sensible specification > onto the frontend of GODI so that it's easier for developers to make > packages. > http://projects.phauna.org/godiva/papers/godiva.ps > http://projects.phauna.org/godiva/papers/godiva.pdf OK, I've read this now, especially the most interesting part, the build policy. Since I don't know what constraints are Godiva's, and which are Godi's and which are bsd's .. I'll just make some comments. I'm going to see how this would go installing Felix. (1) Make all/make opt. What I do is: make compiler make compiler.bytecode There is a reason for this. First, the target is 'compiler' and not 'all'. "all" is a lot more than just the tools generated by ocaml, see below. Second, make compiler automatically makes the native code version if possible, otherwise it makes the bytecode version. The compiler.bytecode target makes bytecode only. (2) make htdoc I wish it were that simple. The felix documentation consists of the following, at least: (a) A complete typeset listing of the source code. (b) An Ocamldoc generated module reference. (c) Several tutorials (d) A reference manual (not written yet :) (e) A users guide (not written yet) (f) Theory and principles papers (not written yet) (g) Typset listing of test inputs (other than the tutorial codes which are in fact the primary unit tests). There are two sections at the moment: special regression and unit tests, and a set of performance tests. (h) Man pages, including HTML formatted versions of them In addition, interscript "in theory" can generate documentation in any language: technically a few navigation bars can be done in English, Spanish etc, however there is a possibility of selecting a non-native language section (a paragraph could be provided in several languages). The point here is that the choice of languages is a mandatory command line parameter: there is, deliberately, no default. Note also the plural. You can simultaneously generate documentation in any number of languages, the files are prefixed by the ISO language code: en_ for english, es_ for spanish, fr_ for French (thought I'd better add that one here .. ). Etc. So there needs to be a way for the client to configure that. [There isn't at present, even in my build scripts] The generated documentation doesn't all go in the same place. The tutorial goes in tutorial/doc. The ocamldep output goes into impldoc, the html listing into doc, and the html man pages into htmlman. (3) Missing targets. First: there are test targets. Running the tests is considered essential. Second: Felix itself is a compiler. Naturally IT has a standard library and there are some tools written in it. These must be built and tested too .. Third: Felix can call C libraries via wrappers. These wrapper have to be generated. At the moment I'm using SWIG with a custom module which can't be used with SWIG without first patching it. So SWIG needs to be relinked and installed (the patched version makes an extra executable). Then there has to be a way to determine *which* libraries to wrap. The current method is intended to be: everything there is a SWIG wrapper for, if the library exists, PLUS, every library in the systems pkg-config database PLUS any the user specifies. Wrappers get generated even if there is no SWIG annotation file. Maybe :D (4) Bootstrapping problem. Felix consists of LP source codes. When you unpack the tarball, there is a 'courtesy' makefile to bootstrap the system. To get the thing rolling you have to do this: make boot ./configure make extract compiler drivers tests ....... The actual Makefile.ac is extracted by make boot, then configure creates the makefile from it. Make boot currently runs autoconf and friends to generate the configure script from configure.ac. ------------------------------------------------------------- INSTALLATION Felix installs much as described in A.1, except there is more. In fact some components are a nightmare. For example 'felix.vim' has to go in /usr/local/share/vim/vim61/syntax but that isn't enough (some other files have to be patched) which is a design flaw in vim. Much of Felix actually lives in /usr/local/lib/felix because this is the kind of thing Ocaml and Python do. The suggested /usr/local/share/felix isn't used, because most of the shared data is actually Felix program source. The installation point for generated wrappers is a nightmare! ---------------------------------------------------- RECOMMENDATIONS A mandatory make test target. The test must be run by GODI, and installation refused if it fails. More is needed but my brain is overloaded now :D -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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