On Fri, 2004-04-16 at 11:30, Richard Cole wrote:

> >
> Please forgive my ignorance of interscript but I'm interested in what 
> problem interscript is trying to address. 

Package, build, test and document software systems using a 
unified source format. As a Literate Programming tool, 
you don't document your code .. you embed code in a document.

Interscript is unique as follows. Most LP tools divide sources
into 2 kinds: (a) documentation (b) source program codes. 
You use a tool to do two jobs: (a) extract the code (b) generate
the documentation. Called 'tangling' and 'weaving'.

Interscript sources can have a third kind of stuff in it. 
Arbitrary executable code written in a high level language (Python).
I use executable code to generate programs, to generate documentation,
to compile code, to run test suites, to do configuration management,
and everything else. Some of these things have library and architecture
support, for example a registry for test results which is part of the
generated web site, other things do not: extensions may improve
the product, but you can always embed them directly and install
them as part of the build.

> Another aspect of building systems is configuration management. This is 
> where my question really is. I've only worked on systems where 
> configurations differed via library dependencies. So for example the 
> linux version links to the linux-lowlevel library and the windows 
> version links to the window-lowlevel library. Is there some other aspect 
> of configuration management that interscript addresses?

Not in particular: it doesn't really address anything.
It simply allows you to embed configuration management
code directly in the source tree in a uniform format.

Well, there are some interesting ideas: for example you can
'include' a generated file before it is generated. No problem!
That's because the idea is to run the build repeatedly until
the outputs converge to a fixpoint: if something fails
the first time it doesn't matter, just keep trying :D

This is already clearly mandatory for LaTeX, and if you think
about it is the only way to manage systems that bootstrap.

> is much better to select tools that are supported on all the platforms 
> that you want to deploy your system. That pushes the "supporting 
> different build environments" problem onto someone else.

Yeah, I chose Python. Shell script is too Unix centric,
and it just doesn't compare with a real programming language:
you don't need hacks kludges and glue to make it work.

The downside is that being general purpose, a high level language
like Python (or Ocaml) will need more code to get simple
jobs done. That's the price for being able to write code
for any job, no matter how complex, and knowing for SURE that
you will not be defeated by restrictions of more specialised tools.

Hey, you write code in Ocaml because it's not going to get
in your way like C++ does .. and isn't building a system
just another programming problem?


-- 
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