From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA01529 for caml-redistribution@pauillac.inria.fr; Fri, 25 Feb 2000 18:12:29 +0100 (MET) Resent-Message-Id: <200002251712.SAA01529@pauillac.inria.fr> 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 RAA28737 for ; Fri, 25 Feb 2000 17:51:15 +0100 (MET) Received: from ruby (kyle100.zip.com.au [61.8.17.228]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id RAA05937 for ; Fri, 25 Feb 2000 17:51:09 +0100 (MET) Received: from maxtal.com.au (IDENT:root@localhost [127.0.0.1]) by ruby (8.9.3/8.9.3) with ESMTP id DAA24865; Sat, 26 Feb 2000 03:51:58 +1100 Sender: root@ruby Message-ID: <38B6B32E.44F54B62@maxtal.com.au> Date: Sat, 26 Feb 2000 03:51:58 +1100 From: skaller Organization: Maxtal X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.12 i586) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Pfitzenmaier CC: caml-list@inria.fr Subject: Re: Portability of applications written in OCAML: C stuff References: <200002251229.NAA07017@sunhelmet.informatik.uni-tuebingen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-From: weis@pauillac.inria.fr Resent-Date: Fri, 25 Feb 2000 18:12:29 +0100 Resent-To: caml-redistribution@pauillac.inria.fr Juergen Pfitzenmaier wrote: > > Max Skaller wrote on Wed, 23 Feb 2000 10:43:46 +1100 > > 1. DO NOT USE A FILE CALLED 'config.h' > .... > > do NOT use generic names on the assumption your code will > > be built with your Makefile in a separate directory. > > I have seen some big projects (> 100 MB code) and several smaller ones. In each of > them people had to fight with the configuration. They all settled for what seems to > be the least pain: built and distribute (!) in small blocks; keep each block in its > own directory; use the same general frame for each block if possible (yes: use the > name config.h over and over again). > Even if its leading away from OCaml: I think that your real problem is with "make" > and its way of building project. Look for "configuration management" and "make replacement" > on the net. no thanks. you see, I have a vastly superior system. It is called interscript. (http://interscript.sourceforge.net). Interscript is a literate programming tool written in Python. Interscript 'script' is Python too. This replaces _completely_ all configuration control, takes responsibility not only for compiling target software -- and of course, documenting it -- but also testing and installing it. Unlike like 'make', 'autoconf' and various lame shell scripts, Python is a full scale general purpose programming language. Interscript, being experimental, does not yet provide the uniform language independent (and that includes human languages as well as programming languages) build platform I'd like it to, and it is a bit slow generating large documents. For this reason, I an writing a fast, fully featured, Python compatible interpreter call Vyper (http://Vyper.sourceforge.net), which is designed to support later building of a compiler. Vyper is written in Ocaml. The current version of Vyper is not literate programmed, and it won't be until Vyper executes interscript satisfactorily. [One of the main hang ups is finalising Python class instance objects -- which means executing their __del__ methods, in the correct order(ocaml 2.999 finalisers work, but finalise the objects in the wrong order at present). The combination of Vyper and Interscript will be a rather amazingly powerful tool -- compared with make, autoconf, and shell script. Interscript programs are distributed as sets of text files. Rarely are subdirectories needed, mainly because an interscript source is a level of abstraction above a standard source code source file. [Interscript itself, for example, has a tree like directory structure of Python packages, but the original sources typically contain a whole directory contents in a few files (interscript is 'verging' on needing subdirectories for the source).] In a sense, interscript sources are 'self extracting archives'. And unlike other methods of packaging 'free' or other software sources, you _always_ get documentation (even if it is only a program listing :-) As to autoconf -- it may well make sense to run it _once_ to build a configuration library interscript can use to control the building of software. But typically, the ability of interscript to _generate_ code provides a vastly superior method of configuration to hackery like C macros, conditional compilation, and other weird C'isms (that won't work with other languages). So my aim is to eventually distribute Vyper as interscript source (as interscript itself is distributed, together with a prebuild version for bootstrapping). And that means I need to get rid of subpackage makes, autoconfs, and other things, so as to unify the distribution mechanism. So you see, you're quite right: > Even if its leading away from OCaml: I think that your real problem is with "make" > and its way of building project. but >Look for "configuration management" and "make replacement" on the net. I'be been programming for quite some time, and I know how the ludicrous make and configuration systems people use on systems, including Unix and Windows, work -- or should I say, _fail_ to work. This is well known. Why else would Redhat, for example, have created rpm? (that doesn't work so well either ..) -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net