Re: [Caml-list] Re: GODI vs. Ocamake

[Richard Cole <rcole@itee.uq.edu.au>]

skaller wrote:

>On Thu, 2004-04-15 at 19:47, Markus Mottl wrote:
>  
>
>>On Thu, 15 Apr 2004, skaller wrote:
>>    
>>
>>>On Thu, 2004-04-15 at 02:49, Kenneth Knowles wrote:
>>>
>>>      
>>>
>>>>Just so I don't leave anyone out, I'd say both ocamake and OCamlMakefile handle
>>>>(1) and (3) all at once.
>>>>        
>>>>
>>>Yeah? How would they handle Interscript sources?
>>>What about Camlp4?
>>>      
>>>
>>No problem, OCamlMakefile handles them by letting the user specify a
>>preprocessor in a comment in the first line.  See camlp4-example in
>>the distribution.
>>    
>>
>
>That may work for camlp4 but not interscript.
>Interscript is a code generator, there is no simplistic
>1-1 correspondence between inputs and outputs for which
>any make rule could be encoded.
>
>Make is all wrong, as I said before. Interscript is a new,
>correct concept for building systems. It uses fixpoints.
>It doesn't care what the outputs are --- they have to be tracked,
>but not specified.
>  
>
Please forgive my ignorance of interscript but I'm interested in what 
problem interscript is trying to address. I understand that it makes 
sense to document code using some simple hypertext language -- something 
similar to WikiLanguages -- that allows you to make references to code 
artifacts, include diagrams etc.

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?

The way that I now build makefiles is with tcl.

set projects { pig }
set ml_sources(pig) { one two three }
set mli_sources(pig) { two }

for y in $projects {


  #  Create .cmo files
 
  for x in [get ml_sources $y] {  
    if { [is_member $x [get mli_sources $y]] } {
      set mli_source $x
    } else {
      set mli_source ""
    }

    puts "$x.cmo: $x.ml $mli_source.mli"
    ...
  }
}

I find that this approach allows me to factor out the stuff that is 
repeated between projects and use variables to denote the stuff that 
changes between projects. This is kind of a moving target because as 
code develops what is common and what is different between projects changes.

Another aspect of configuration management is knowing which libraries a 
version of your project depends on. There are source level dependencies 
and after you build libraries there are binary level dependencies. This 
problem seems to be tackled in two ways: (i) package managers of which 
godi is a nice example, and (ii) autoconf which alleviates some source 
level dependencies by hacking the code in sometimes evil ways.

Another issue comes to mind. Under linux it seems that libraries have 
version numbers, libc.so.3.0.0 and the like. I haven't seen how this 
works with godi? Can you install multiple versions of an Ocaml package 
and pass version information to Ocamlfind? If not why not? Is the case 
of multiple deployed library versions something we are striving to 
avoid? I think for the user it is inescapable, e.g. my desktop requires 
both gtk-1.2 and gtk-2.0.

There is another type of dependency which is very nasty to support and 
one that I think we should strive to avoid, where possible. The same 
project supporting quite different build environments. Say for example 
that you want to want to write a build script that uses either CSH or 
KSH, whatever is available [1]. Now say that it is not possible to 
automatically, in general, convert CSH into KSH, so you write a 
conversion program that doesn't work in general, but works for your 
build script. This is going to make a difficult to understand mess, it 
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.

regards,

Richard.

[1] I'm not advocating the use of build scripts in either csh or ksh 
just using them as an example.


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