Version française
Home     About     Download     Resources     Contact us    
Browse thread
[OT] Rant about VCS
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] [OT] Rant about VCS
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