From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id AEBD1BB81 for ; Sat, 18 Dec 2004 01:48:39 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iBI0mdke012462 for ; Sat, 18 Dec 2004 01:48:39 +0100 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 BAA20521 for ; Sat, 18 Dec 2004 01:48:38 +0100 (MET) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iBI0maOi031860 for ; Sat, 18 Dec 2004 01:48:38 +0100 Received: from [192.168.1.200] (ppp196-155.lns1.syd2.internode.on.net [203.122.196.155]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id iBI0mSRF020605; Sat, 18 Dec 2004 11:18:29 +1030 (CST) Subject: Re: [Caml-list] [OT] Rant about VCS From: skaller Reply-To: skaller@users.sourceforge.net To: Alex Baretta Cc: Ocaml In-Reply-To: <41C3126A.3060101@barettadeit.com> References: <41C3126A.3060101@barettadeit.com> Content-Type: text/plain Message-Id: <1103330908.4711.149.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 18 Dec 2004 11:48:28 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 41C37E67.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41C37E64.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 baretta:01 wrote:01 subpackages:01 kloc:01 ocaml:01 ocaml:01 cvs:01 sourceforge:01 cvs:01 literate:01 mli:01 val:01 pairs:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: On Sat, 2004-12-18 at 04:07, Alex Baretta wrote: > Please forgive me for ranting about source code Version Control Systems > on the list, but I can't help it. Besides, I would like to know what the > gurus on the list use to manage their own projects. Well, I solve the build complexities using interscript. The principle packaging concept is a simple set of subpackages, each of which is a plain text file. One file is the main one. It is processed like iscr main.pak This command builds the actual distribution file set. Moving files around, adapting them for the platform, etc, are all handled *within* this system. For example I use Cil -- this is packaged up as two files: flx_frontc.ipk and flx_cil.ipk (Cil is built on top of frontc). Most of my build scripts are packaged in flx_maker.ipk. I have several sets of tests, eg: flx_tutorial.ipk is the tutorial (which is also a test suite). Using any version control system to manage detail level files is really archaic. Interscript is a much better solution. Wc on my LP archive shows: 93781 374389 2674323 total which is 2 1/2 meg of pure source code, 370Kloc, in 89 files. Of course the actual 'source' code is bigger, since some is generated. The package includes (0) Interscript -- python tree containing the extract tool (a) Felix (ocaml + C++) (b) OCS scheme (ocaml) -- ONE file (c) FISh 1.6 (Ocaml) -- ONE file (d) Frontc (Ocaml) -- ONE file (e) CIL (Ocaml) -- ONE file (f) Elkhound (C++) -- THREE files and coming: (g) Lua Now it happens that I am using CVS on Sourceforge. On my network link this is a PAIN it is so slow. But whilst there may still be a need to 'move directories' around etc, I haven't run into it yet. When I reorganise the 'source' code that reorganisation is entirely built into the internal interscript LP structure -- CVS never sees it. At worst I occasionally delete a file or add a file. Although originally designed as a Literate Programming tool, I am not really using interscript for that much: I'm using it as an advanced package manager instead. Just simple things like this: @h = tangler("src/flx_xxx.ml") @select(h) let f x = x .... @h = tangler("src/flx_xxx.mli") @select(h) val f:int -> int .... which allows you to group files is a major bonus. The other is: lines starting with @ are arbitrary Python script. For example: ... @keywords = ['fred','joe'] @for i in keywords: tangle('(' + str i +',"' + str i+'")') @# generates a nice table of pairs (fred,"fred") etc This is *infintely* superior to rubbish like template files which some script fills in (eg autoconf style rubbish): it is universally available and arbitrary code can generate any part of any file in any way -- code generation is *local* not external. You could probably implement your own tool to do this, say in Scheme instead of Python: all you really need to do it is 'eval'. The downside is: you MUST not edit 'source' code. Instead you edit the source generators, which implies after every change you have to re-extract your source tree. [Interscript is smart, and only re-extracts changed subtrees] This also means no syntax colouring or building inside emacs (unless you extend it to handle the tool). The upside is -- recent change to Elkhound, Scott used 'string' as a class name which isn't nice -- fixed with 6 global search and replace in Vim. (3 files, 2 changes since '#include "string.h"' was screwed up by the first replace). That is, systematic editing is easier because all the related 'files' are in one file. Also does nice things like copy '*.mli' files to '*.ml' files when they're the same file .. etc etc. To really understand how all this works, you could just try it :) http://felix.sf.net/download.html You'll note even though I have a Python maker script, I still generate a conventional Makefile and use it to do the top level making, and also to bootstrap the build process (the Makefile you get out of the tarball is immediately clobbered by a generated one). -- 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