caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Alex Baretta <alex@barettadeit.com>
Cc: Ocaml <caml-list@inria.fr>
Subject: Re: [Caml-list] [OT] Rant about VCS
Date: 18 Dec 2004 11:48:28 +1100	[thread overview]
Message-ID: <1103330908.4711.149.camel@pelican.wigram> (raw)
In-Reply-To: <41C3126A.3060101@barettadeit.com>

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




  parent reply	other threads:[~2004-12-18  0:48 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-17 17:07 Alex Baretta
2004-12-17 18:42 ` [Caml-list] " Paul Snively
2004-12-17 19:28   ` Yaron Minsky
2004-12-17 20:13   ` Erik de Castro Lopo
2004-12-17 21:37 ` Sven Luther
2004-12-17 22:27   ` Erik de Castro Lopo
2004-12-18  9:28     ` Sven Luther
2004-12-18  9:49       ` Erik de Castro Lopo
2004-12-18 14:45         ` Sven Luther
2004-12-18 20:03           ` Erik de Castro Lopo
2004-12-18  9:52       ` Erik de Castro Lopo
2004-12-18 14:45         ` Sven Luther
2004-12-18 11:24       ` Richard Jones
2004-12-18 15:01         ` Sven Luther
2004-12-18 15:22           ` Richard W.M. Jones
2004-12-18 15:35             ` Richard W.M. Jones
2004-12-18 15:39             ` Sven Luther
2004-12-21  9:07     ` [Caml-list] [OT] Rant about VCS: Conclusions Alex Baretta
2004-12-21 22:03       ` Blair Zajac
2004-12-21 22:36         ` Erik de Castro Lopo
2004-12-21 23:19           ` David Brown
2004-12-21 23:47             ` Erik de Castro Lopo
2004-12-18  0:48 ` skaller [this message]
2004-12-18 11:25 ` [Caml-list] [OT] Rant about VCS henri dubois-ferriere
2004-12-18 15:03   ` Sven Luther
2004-12-17 18:42 Ennals, Robert
2004-12-17 20:01 ` Alex Baretta
2004-12-17 20:27   ` Paul Snively
2004-12-20  8:27     ` Peter Busser
2004-12-17 20:36   ` Erik de Castro Lopo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1103330908.4711.149.camel@pelican.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=alex@barettadeit.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).