[Caml-list] Building large and portable projects

[Caml-list] Building large and portable projects

[Martin Jambon]

Hi,

Is there a convenient way to develop OCaml code, and be sure that 
this code will be configurable, compilable, installable and 
executable without changes, on any environment where OCaml is available?

I imagine a higher level "make", with most of its nicer properties, plus 
many enhancements.
The following points seem important to me:

- target dependency system
- ease of use, nice syntax (for average humans with a simple text editor)
- loadable modules
- built-in programming language
- built-in fileutils (cp, mv, cd, rm, ...) and functions (filters, ...)
- universal paths for filenames inside the project tree
- natural highlighting of environment-dependent elements
- possibility of harmonious integration in a graphical development 
  environment

and also a very flexible license that allows its free redistribution and 
modification under any form.

Until right now I didn't find anything like this. And I was really scared 
when I discovered Apache Ant.

Any suggestions?


Martin

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

Re: [Caml-list] Building large and portable projects

[sylvain.le-gall]

Hello,

On Thu, Nov 20, 2003 at 07:47:25PM +0100, Martin Jambon wrote:
> Hi,
> 
> Is there a convenient way to develop OCaml code, and be sure that 
> this code will be configurable, compilable, installable and 
> executable without changes, on any environment where OCaml is available?
> 

The only way is to use only pure ocaml code ( not C binding ). With this
you are pretty sure not to have any problem. (Exclude for example Unix,
Dbm modules ).

> I imagine a higher level "make", with most of its nicer properties, plus 
> many enhancements.
> The following points seem important to me:
> 
> - target dependency system
> - ease of use, nice syntax (for average humans with a simple text editor)
> - loadable modules
> - built-in programming language
> - built-in fileutils (cp, mv, cd, rm, ...) and functions (filters, ...)
... Try ocaml-fileutils ...
> - universal paths for filenames inside the project tree
... Try ocaml-fileutils ...
> - natural highlighting of environment-dependent elements
> - possibility of harmonious integration in a graphical development 
>   environment
> 
> and also a very flexible license that allows its free redistribution and 
> modification under any form.
> 
> Until right now I didn't find anything like this. And I was really scared 
> when I discovered Apache Ant.
> 

Well let me give you some hints :
Ocaml fileutils is a lib of mine ( not yet published, but if you want to
test it, i can give you the tar ball ).

In fact, my aim is to construct approximativelly what you are looking for 
but for now, i have not yet the time to go over the whole things. 

Ocaml-fileutils is the base path abstraction for files and fileutils.
Ocaml-preprocessor is a replacement for *.in -> * ( already developped,
very simple, it is something were you bind variable and function and
you pass it on files where there is for example @funct "abcd"@ and it
replace it with the result of the binding of funct "abcd"... ). It is
also not yet published, but it seems stable to me.

I want to develop the makefile in ML. Each module will register
variable, target, dependency and a big program will run to compute all
this and compile file, lib, exec...

For now, it is only at an early stage ( i have some lexer/parser to
autosort ocamldep generated file and try to figure how to compile only
one thing ).

If you are intersted, just drop me an email, to have more information,
or if you want to test ocaml-fileutils or ocaml-preprocessor.

Kind regard
Sylvain LE GALL

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

Re: [Caml-list] Building large and portable projects

[Nicolas Cannasse]

[...]
> I want to develop the makefile in ML. Each module will register
> variable, target, dependency and a big program will run to compute all
> this and compile file, lib, exec...
> 
> For now, it is only at an early stage ( i have some lexer/parser to
> autosort ocamldep generated file and try to figure how to compile only
> one thing ).
[...]

What is the difference with OCamake ?
http://tech.motion-twin.com/ocamake/

Nicolas Cannasse

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

Re: [Caml-list] Building large and portable projects

[David Brown]

On Fri, Nov 21, 2003 at 10:45:47AM +0900, Nicolas Cannasse wrote:

> What is the difference with OCamake ?
> http://tech.motion-twin.com/ocamake/

There are a lot of things that OCamake can't do.  What would be very
nice would be a tool that makes it easy to build simple Ocaml programs,
but also lets me, reasonably easily, manage directory trees, C bindings,
C libraries, programs build with special, strange programs, etc...

There are several packages in the scons approach that seem like good
ideas, but they all make very heavy use of the scripting languages they
are written in.

I still haven't found anything nicer than gnatmake, the builder for Gnu
Ada.  A common compilation line:

  gnatmake mainmodule

Builds mainmodule.adb, as well as everything it depends on.  You can set
a path to search for parts.  This would work for ocaml, if a program had
a single module that brought in everything necessary via dependencies.

Dave

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

Re: [Caml-list] Building large and portable projects

[Nicolas Cannasse]

> > What is the difference with OCamake ?
> > http://tech.motion-twin.com/ocamake/
>
> There are a lot of things that OCamake can't do.  What would be very
> nice would be a tool that makes it easy to build simple Ocaml programs,
> but also lets me, reasonably easily, manage directory trees, C bindings,
> C libraries, programs build with special, strange programs, etc...
>
> There are several packages in the scons approach that seem like good
> ideas, but they all make very heavy use of the scripting languages they
> are written in.
>
> I still haven't found anything nicer than gnatmake, the builder for Gnu
> Ada.  A common compilation line:
>
>   gnatmake mainmodule
>
> Builds mainmodule.adb, as well as everything it depends on.  You can set
> a path to search for parts.  This would work for ocaml, if a program had
> a single module that brought in everything necessary via dependencies.

I agree such a thing would be very useful.

The first problem I see is that right now ocamldep is only giving you the
dependencies between files that are listed in the ocamldep command. That
means that you already need to know all the files before generating the
dependencies between them.

The other problem is that to much of the "special programs build" are
relying on OS tools that are sometimes not stricly compatible. The solution
to this is to rewrite all the tools in pure ocaml ( or with a small portable
C binding ) to give the "makefile" writter an API of portable commands. It
looks like this is the goal of Sylvain, and that would be really something
nice.

About OCamake : yes right know it only supports compilation of
ml/mli/mll/mly files in a standard way, but it is now mature and is actually
handling a lot of cases such as projects with multiple files paths and a
best effort dependency resolver (although based on ocamldep output). Adding
the auto building of C stubs could be done but this kind of tool need a lot
of time in order to fix correctly all the small issues.

Nicolas Cannasse


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

Re: [Caml-list] Building large and portable projects

[David Brown]

On Fri, Nov 21, 2003 at 02:48:17PM +0900, Nicolas Cannasse wrote:

> The first problem I see is that right now ocamldep is only giving you the
> dependencies between files that are listed in the ocamldep command. That
> means that you already need to know all the files before generating the
> dependencies between them.

Start with the module you know.  As long as the path is right, ocamldep
will give you the dependencies for the files it referrs to (they don't
have to be named, as long as their source is in the path).  You can keep
doing this to get a full name.  Ocamake seems to be able to do it.

Dave

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

Re: [Caml-list] Building large and portable projects

[sylvain.le-gall]

On Fri, Nov 21, 2003 at 02:48:17PM +0900, Nicolas Cannasse wrote:
> > > What is the difference with OCamake ?
> > > http://tech.motion-twin.com/ocamake/
> >
> > There are a lot of things that OCamake can't do.  What would be very
> > nice would be a tool that makes it easy to build simple Ocaml programs,
> > but also lets me, reasonably easily, manage directory trees, C bindings,
> > C libraries, programs build with special, strange programs, etc...
> >
> > There are several packages in the scons approach that seem like good
> > ideas, but they all make very heavy use of the scripting languages they
> > are written in.
> >
> > I still haven't found anything nicer than gnatmake, the builder for Gnu
> > Ada.  A common compilation line:
> >
> >   gnatmake mainmodule
> >
> > Builds mainmodule.adb, as well as everything it depends on.  You can set
> > a path to search for parts.  This would work for ocaml, if a program had
> > a single module that brought in everything necessary via dependencies.
> 
> I agree such a thing would be very useful.
> 
> The first problem I see is that right now ocamldep is only giving you the
> dependencies between files that are listed in the ocamldep command. That
> means that you already need to know all the files before generating the
> dependencies between them.
> 
> The other problem is that to much of the "special programs build" are
> relying on OS tools that are sometimes not stricly compatible. The solution
> to this is to rewrite all the tools in pure ocaml ( or with a small portable
> C binding ) to give the "makefile" writter an API of portable commands. It
> looks like this is the goal of Sylvain, and that would be really something
> nice.
> 
> About OCamake : yes right know it only supports compilation of
> ml/mli/mll/mly files in a standard way, but it is now mature and is actually
> handling a lot of cases such as projects with multiple files paths and a
> best effort dependency resolver (although based on ocamldep output). Adding
> the auto building of C stubs could be done but this kind of tool need a lot
> of time in order to fix correctly all the small issues.
> 
> Nicolas Cannasse

Hello,

Well, i will maybe stole your code ;->

My aims is to make something more Makefile like ( ie you will have the
ability to add rules ). Off course, my first goal is to compile ml file.
So there will be less features than Makefile.

On the other hand the aim will be to have a self contained tools ( ie
when you write a makefile you use rm, cp, touch... here the aims will be
to have it in ocaml ). So you could build on every platform which
support ocaml.

Your makefile will be written in ocaml !

Regard
Sylvain LE GALL
> 

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

Re: [Caml-list] Building large and portable projects

[Christian Lindig]

On Thu, Nov 20, 2003 at 09:25:49PM -0800, David Brown wrote:
> I still haven't found anything nicer than gnatmake, the builder for Gnu
> Ada.  A common compilation line:
> 
>   gnatmake mainmodule
 

There is an inherent tension between large projects and writing a tool
like gnatmake: large projects are not entirely written in OCaml, or any
other single language. 

While it is possible to write a tool that is smart about OCaml, it can't
know about about all the other tools you are using to generate
documentation, or to generate OCaml code from some specification
language. A make replacement therefore must be language-neutral. You
still could write a tool that handles recompilation of pure OCaml
projects but you would have to use it from a language-neutral make
replacement in truly large projects.

Ocamldep is a simple example for such a tool: it is smart about OCaml
but it emits Make syntax and does not try to solve the problem that Make
can solve better.

-- Christian

-- 
Christian Lindig         http://www.st.cs.uni-sb.de/~lindig/

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

Re: [Caml-list] Building large and portable projects

[Richard Jones]

On Thu, Nov 20, 2003 at 07:47:25PM +0100, Martin Jambon wrote:
> Until right now I didn't find anything like this. And I was really scared 
> when I discovered Apache Ant.

One hopes such a tool won't be as slow or as hard to use or as
stupidly architected as Apache Ant ...

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
PTHRLIB is a library for writing small, efficient and fast servers in C.
HTTP, CGI, DBI, lightweight threads: http://www.annexia.org/freeware/pthrlib/

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

Re: [Caml-list] Building large and portable projects

[skaller]

On Fri, 2003-11-21 at 05:47, Martin Jambon wrote:
> . And I was really scared 
> when I discovered Apache Ant.

Excuse my ignorance but what is that?
A bug generator?? <g>
-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:25/85c Wigram Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850. Checkout Felix: 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

Re: [Caml-list] Building large and portable projects

[skaller]

On Fri, 2003-11-21 at 17:49, sylvain.le-gall@polytechnique.org wrote:
> On Fri, Nov 21, 2003 at 02:48:17PM +0900, Nicolas Cannasse wrote:

> On the other hand the aim will be to have a self contained tools ( ie
> when you write a makefile you use rm, cp, touch
> .. here the aims will be
> to have it in ocaml ). So you could build on every platform which
> support ocaml.

The goal is impossible. For example, all my Ocaml
source is literate programmed. You surely aren't
going to rewrite Interscript in Ocaml are you?

At best, you can cheat with system() function
but then all the dependency checking is lost.

Make systems are all conceptually wrong.
There a huge number of projects to replace
Make (and autoconf et al) and not a single
one I've seen recognizes that the fundamental
design is flawed .. instead they all try to
copy the make idea.

First observe that building a system
is a process where it is not always
possible to determine the full sequence
of commands in advance. Sometimes,
you have to perform some action before
you can decide what to do next.

Example: you cannot build interscript
packaged sources or a tarball directly,
you have to extract the contents first.

Example: the rules for building a package
may have to be generated or extracted
from the package.

Next observe that the linear dependency
checking is naive. First, what some
target depends on can be conditional:
obviously true for C :-)

But it is much worse. A target can
depend on itself. Interscript assumes that.
An example is a Latex build, which depends
on auxilliary files generated by the build
[Ocamldoc output can take 4 passes to fixate
for example].

This leads to the first novel idea. Fixpoints.
Interscript is based on that idea.

With fixpoints, you dont CARE about dependencies.
What you do is repeatedly execute some process
until the defined outputs are stable. The inputs
do not need to be known.

Now we backstep. We try to *predict* whether
the outputs will be the same this run as last.
If we can -- and we have to be *sure* -- we
can terminate one cycle earlier.

This is dependency checking with a new twist:
its optional. :-)

Well, I will jump ahead now. A build system
does NOT have targets. That's a bad idea too.

A build systems has processes and files.
Lets call the processes ARROWS and the files OBJECTS.

Oh. That's a category. We allow of course,
products of files (multiple outputs and inputs)
and sums of files (choose one of several).
[And of course we'd better make it cartesian
closed and allow processes to be files .. 
called scripts .. :]

The control system allows you to 'click' on
an arrow to execute the process. This is manual
running. It also allows to to click on a object
to run all the processes required to produce
the object. By using a caching concept, some
process can be elided as an optimisation.

For example .c -cc--> .o -link--> exe, we can 
use the cached .o instead of running cc on the
.c provided the .c is older.

BTW: I have *built* this system, including
a graphic interface which allowed construction
of the build category.

I needed this much power. Make is a total joke.
What I was doing was writing a book, literate
programmed of course, and needed to generate
a LOT of different documents -- I had to build
code, test it, capture the output, typeset
the book, build indices, contents ...

In a *real* build system, you do NOT want
to make everything from scratch everytime.
Sometime you're happy using old data,
at least for a while.

Anyhow .. a lot of new ideas for a build
system are here. Just copying the make concept
is not going to solve any problems .. its going
to make things much WORSE by having yet another
inadequate tool -- which of course the poor client
will have to build, making the tool chain even longer.
[Trying to replace Make destroyed Boost IMHO]



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

Re: [Caml-list] Building large and portable projects

[Martin Jambon]

On Fri, 21 Nov 2003 sylvain.le-gall@polytechnique.org wrote:

> My aims is to make something more Makefile like ( ie you will have the
> ability to add rules ). Off course, my first goal is to compile ml file.
> So there will be less features than Makefile.

Are you sure? If this compiles only Caml code, nobody will use it for 
serious projects. But I was thinking of loadable modules like in emacs 
instead of a rigid and limited set of predefined rules.
If we think of make as a preprocessor for shell-scripts, then we can 
create a preprocessor for OCaml that will do the same but will benefit 
from many built-in properties that sh doesn't have and that (GNU) make 
hardly provides.

Martin

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

Re: [Caml-list] Building large and portable projects

[Jason Hickey]

[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]

Martin Jambon wrote:
> Is there a convenient way to develop OCaml code, and be sure that 
> this code will be configurable, compilable, installable and 
> executable without changes, on any environment where OCaml is available?

We have been using omake to build several large projects, primarily on 
Linux and Windows.  omake is written in OCaml, and provides a build 
system with syntax similar to make, but project-wide dependency 
analysis.  Here are some features:

     - omake runs on Unix, Windows, MacOS, and presumably
       other architectures where OCaml is available.
     - dependency analysis is project-wide (like cons),
       based on MD5 digests
     - automated dependency analysis
     - there is builtin support for OCaml and C code,
       and it is easy to add support for other kinds
       of files (just like make).
     - the OMakefile syntax is similar to GNU make, but
         - omake has user-defined functions
         - OMakefile programs are functional
         - the .SUBDIRS target is used to define
           the project hierarchy
         - different parts of the project can have
           different configuration.

omake is available by anonynous CVS from cvs.metaprl.org.
    % cvs -d :pserver:anoncvs@cvs.metaprl.org:/cvsroot login
    The password is anoncvs.
    % cvs -d :pserver:anoncvs@cvs.metaprl.org:/cvsroot checkout omake

Alternatively, RPMs are available at rpm.nogin.org.

Here is a short description.  Every project must have an OMakeroot file 
in the project root.  It is usually boilerplate; this is typical:

    # Include the standard configuration
    include $(STDROOT)

    # Include the OMakefile
    .SUBDIRS: .

The project commands are then placed in an OMakefile.  To build a 
standalone OCaml program from files a.ml b.ml and c.ml, you just need 
one line.  The OCamlProgram function is defined in the system OMakeroot.

    OCamlProgram(foo, a b c)

You can choose the byte-compiler, native-code compiler, or both.

    BYTE_ENABLED = true
    NATIVE_ENABLED = true
    OCamlProgram(foo, a b c)

Maybe you have some C files you need to include in your compile as well. 
  Perhaps f.c is a generated file.

    f.c: f1.c f2.c
	cat $+ > $@
    StaticCLibrary(bar, d e f)
    LIBS = bar
    OCamlProgram(foo, a b c)

Perhaps you use the C-preprocessor on some .mlp files:

    %.ml: %.mlp
	$(CPP) $*.mlp > $@

The system sources contain more examples, and the MetaPRL system, also 
available at cvs.metaprl.org, provides a very large, complex, example.

Jason

-- 
Jason Hickey                  http://www.cs.caltech.edu/~jyh
Caltech Computer Science      Tel: 626-395-6568 FAX: 626-792-4257

[-- Attachment #2: omake.txt --]
[-- Type: text/plain, Size: 13997 bytes --]

omake(1)                    MCC Programmer’s Manual                   omake(1)



NAME
       omake - the omake build system

SYNOPSIS
       omake is a replacement for the make(1) build program.  The omake system
       provides the following additional features.

       Recursive builds

       Omake(1) is designed for building projects that might have source files
       in  several  directories.   In  Omake,  projects are normally specified
       using an OMakefile in each of the project directories, and an OMakeroot
       file in the root directory.  The OMakeroot file specifies general build
       rules, and the OMakefiles specify the build parameters specific to each
       of  the  subdirectories.   When  Omake runs, it walks the configuration
       tree, merging rules from all of the OMakefiles.  The  project  is  then
       built from the entire collection of build rules.

       Automatic dependency analysis.

       Dependency  analysis  has always been problematic with the make(1) pro-
       gram.  Omake addresses this by adding the .SCANNER target, which speci-
       fies a command to produce dependencies.  For example, the rule

          .SCANNER: %.c
             $(CC) $(INCLUDE) -MM $+

       is  the standard way to generate dependencies for .c files.  Omake will
       automatically run the scanner when it needs to  determine  dependencies
       for a file.

       Content-based dependency analysis.

       Dependency  analysis  in  omake  uses  MD5 digests to determine whether
       files have changed.  After each run, omake stores the dependency infor-
       mation in a file called .omakedb in the project root directory.  When a
       rule is considered for execution, the command is not  executed  if  the
       target, dependencies, and command sequence are unchanged since the last
       run of omake.  As an optimization, omake does not recompute the  digest
       for  a  file  that  has an unchanged modification time, size, and inode
       number.

OMakefile
       The OMakefile has a formal similar to Makefile.  An OMakefile has three
       kinds  of  syntac  objects: variable definitions, function definitions,
       and rule definitions.

       Variables

       Variables are defined with the  following  syntax.   The  name  is  any
       sequence of alphanumeric characters, underscore ’_’, and hyphen ’-’.

          <name> = <value>

       Values are represented as a sequence of literal characters and variable
       expansions.  A variable expansion has the form "$(<name>)," which  rep-
       resents  the value of the "<name>" variable in the current environment.
       Some examples are shown below.

          CC = gcc
          CFLAGS = -Wall -g
          COMMAND = $(CC) $(CFLAGS) -O2

       In this example, the value of the COMMAND variable is the  string  "gcc
       -Wall -g -O2".

       Unlike  make,  variable  expansion  is eager, and functional.  That is,
       variable values are expanded immediately and new  variable  definitions
       to  not  affect old ones.  For example, consider the following variable
       definitions.

          X = $(COMMAND)
          COMMAND = $(COMMAND) -O3
          Y = $(COMMAND)

       In this example, the value of the X variable is the string  "gcc  -Wall
       -g -O2" as before, and the value of the Y variable is "gcc -Wall -g -O2
       -O3".

       Functions

       Functions are defined using the following syntax.

          <name>(<params>) = <indented-body>

       The parameters are a comma-separated list of identifiers, and the  body
       must  be  placed  on a separate set of lines that are indented from the
       function definition itself.  For example, the following text defines  a
       function that concatenates its arguments.

          CONCAT(a, b) =
             $(a)$(b)

       Functions  are  called  using  the GNU-make syntax, "$(<name> <args))",
       where "<args>" is a comma-separated list of values.

       Built-in functions

       addsuffix The addsuffix function adds a suffix to each component  of  a
          white-space separated list of strings.  Double-quotes may be used to
          delimit components that contain spaces.

       $(addsuffix <suffix>, <names))
       For example, $(addsuffix .c, a b "c d") expands to a.c b.c "c d".c.

       addprefix The addprefix function adds a prefix to each component  of  a
          white-space separated list of strings.  Double-quotes may be used to
          delimit components that contain spaces.

       $(addprefix <prefix>, <names))
       For example, $(addprefix foo/, a b "c d") expands to foo/a foo/b foo/"c
       d".

       replacesuffixes  The  replacesuffixes  function  modifies the suffix in
          each component of a white-space separated list of strings.

       $(replacesuffixes <old-suffixes>, <new-suffixes>, <names))
       For example, $(replacesuffixes, .h .c, .o .o, a.c b.h c.z)  expands  to
       a.o b.o c.z.

       set  The  set  function  sorts  a set of string components, eliminating
          duplicates.  Note that the quote symbol in  a  string  component  is
          significant.

       $(set <names>)
       For example, $(set z y z "m n" w a) expands to "m n" a w y z.

       not  Boolean  values  in  omake  are  represented  by  case-insensitive
          strings.  The false value can be represented by the  strings  false,
          no, nil, undefined or 0, and everything else is true.  The not func-
          tion negates a Boolean value.

       $(not <value>)
       For example, $(not false) expands to the string true, and  $(not  hello
       world) expands to false.

       equal The equal function tests for equality of two values.

       $(equal <value1>, <value2>)
       For  example  $(equal  a, b) expands to false, and $(equal hello world,
       hello world) expands to true.

       if The if function represents a conditional based on a Boolean value.

       $(if <test>, <value1> <value2>)
       For example $(if $(equal a, b), c, d) expands to d.

       filter-out The filter-out function removes a component  from  a  white-
          space separated list of strings.

       $(filter-out <value>, <names>)$
       For  example $(filter-out a, c d a "hello world") expands to c d "hello
       world".

       file The file and dir functions define location-independent  references
          to  files and directories.  In omake, the commands to build a target
          are executed in the target’s directory.  Since  there  may  be  many
          directories  in  an omake project, the build system provdes a way to
          construct a reference to a file in one  directory,  and  use  it  in
          another  without  explicitly modifying the file name.  The functions
          have the following syntax, where the name should refer to a file  or
          directory.

       $(file <name>) , $(dir <name>)
       For  example,  we can construct a reference to a file "foo" in the cur-
       rent directory.

          FOO = $(file foo)
          .SUBDIRS: bar

       If the FOO variable is expanded in the bar subdirectory, it will expand
       to ../foo.

       These  commands  are  often  used in the top-level OMakefile to provide
       location-independent references to top-level directories, so that build
       commands may refer to these directories as if they were absolute.

          ROOT = $(dir .)
          LIB  = $(dir lib)
          BIN  = $(dir bin)

       Once these variables are defined, they can be used in build commands in
       subdirectories as follows, where $(BIN) will expand to the location  of
       the bin directory relative to the command being executed.

          install: hello
            cp hello $(BIN)


       in  The  in  function is closely related to the dir and file functions.
          It takes a directory and a file, and  gives  the  filename  expanded
          relative  to that directory.  For example, one common way to install
          a file is to define a symbol link, where the value of  the  link  is
          relative to the directory where the link is created.

       $(in <dir>, <file>)
       The following commands create links in the $(LIB) directory.

           FOO = $(file foo)
           install:
              ln -s $(in $(LIB), $(FOO)) $(LIB)/foo

       Rules

       Rules  specify commands to solve a file dependency.  At its simplest, a
       rule has the following form.

       <file>: <files>
          <commands>

       For example, the  following  rule  specifies  how  to  compile  a  file
       hello.c.

       hello.o: hello.c
          $(CC) $(CFLAGS) -c -o hello.o hello.c

       This rule states that the hello.o file depends on the hello.c file.  If
       the hello.c file is newer, the command "$(CC) $(CFLAGS) -c  -o  hello.o
       hello.c" is to be executed to update the target file hello.o.

       A  rule  can have an arbitrary number of commands.  The individual com-
       mand lines are executed independently by the shell sh(1).  The commands
       do  not  have  to  begin with a tab, but they must be indented from the
       dependency line.

       Rules can also be implicit. That is, the  files  may  be  specified  by
       wildcard  patterns.  The wildcard character is %. For example, the fol-
       lowing rule specifies a generic way to build .o files.

       %.o: %.c
          $(CC) $(CFLAGS) -c -o $@ $*.c

       This rule is a general rule to build an arbitrry  .o  file  from  a  .c
       file.   The  variables  $@ and $* are special.  The following variables
       may be used in rules.

       $*: the target name, without a suffix.
       $@: the target name.
       $^: a list of the sources, with duplicates removed.
       $+: a list of the sources, dpulicates are not removed.
       $<: the first source

       Unlike normal values, the variables in a rule body are expanded lazily,
       and  binding is dynamic.  The following function definition illustrates
       some of the issues.

       CLibrary(name, files) =
          OFILES = $(addsuffix .o, $(files))
          $(name).a: $(OFILES)
          $(AR) cq $@ $,(OFILES)

       This function defines a rule to build a program called name from a  set
       of .o files.  The files in the argument are specified without a suffix,
       so the first line of the function definition defines a variable  OFILES
       that  adds  the  .o  suffix  to  each of the file names.  The next step
       defines  a  rule  to  build  a  target  library  "$(name).a"  from  the
       "$(OFILES)"  files.  The variable expansion "$,(OFILES)" specifies that
       eager expansion should be used on the OFILES variable.

       Special targets

       .PHONY The ".PHONY" target specifies that a target name does not  actu-
          ally  correspond to a file.  Phony targets are often used to specify
          extra dependencies.  For example, the  "all"  target  is  frequently
          used  to  specify  a  set  of  files  that  should be constructed by
          default, but the "all" target does not correspond to a file.
             .PHONY: all
             all: hello.o

       .DEFAULT Omake does not build the target specified by the first rule in
          an  OMakefile  (since  there  are several OMakefiles).  The .DEFAULT
          phony target specifies what targets should be built by default.
             .DEFAULT: hello.o

       .SCANNER The ".SCANNER" target specifies a command  to  produce  depen-
          dency  information  for  a  file.  The command should produce output
          that is compatible with omake.  For example, the following rule uses
          gcc(1) to generate dependencies for .c files.
             .SCANNER: %.c
               $(CC) $(CFLAGS) -MM $^

       .SUBDIRS  The  ".SUBDIRS" target is used to specify subdirectories con-
          taining omake projects.  Each of the subdirectories should  have  an
          OMakefile.  For example, the following line specifies a project with
          three sub-projects: foo, bar, and baz.
             .SUBDIRS: foo bar baz
          The current environment is inherited by  the  subdirectories.   This
          can  be useful if different options are ot be used in different sub-
          directories.  For example, the  following  lines  specify  that  foo
          should  be  built  in  debug mode, while bar and baz should be opti-
          mized.
             CFLAGS = -g
             .SUBDIRS: foo
             CFLAGS = -O2
             .SUBDIRS: bar baz

NOTES
       Variables in omake are functional, and new variable definitions  shadow
       old  ones.  In some cases it is convenient to specify a separate set of
       variables for different build targets.  A frequent idiom in  this  case
       is to use a trivial conditional to define a separate scope.
          if 1
             CFLAGS = -g
             .SUBDIRS: foo
          .SUBDIRS: bar baz

       The  "CFLAGS  = -g" variable is defined in a scope used only by the foo
       subdirectory, not by the bar and baz directories.

       It is generally suspected that omake contains a special prize ^_^

FLAGS
       -k: do no stop when an error is encountered.
       -j <jobs>: specify the maximum number of parallel jobs to run.
       -n: do not execute the commands to build the  target,  but  print  what
       would be executed instead.
       -s: be silent and do not print commands as they are executed.
       -t: "touch" the database to make it seem that all files are up to date.
       -U: flush the dependency cache and rebuild all files from scratch.
       -u: a weaker version of the above that keeps the dependency  cache  but
       requires that the OMakefile configuration tree be re-read.

FILES
       OMakefile, OMakeroot

SEE ALSO
       make(1)



LibMojave                         2003-04-12                          omake(1)

Re: [Caml-list] Building large and portable projects

[Eric Dahlman]

skaller wrote:

> But it is much worse. A target can
> depend on itself. Interscript assumes that.
> An example is a Latex build, which depends
> on auxilliary files generated by the build
> [Ocamldoc output can take 4 passes to fixate
> for example].
> 
> This leads to the first novel idea. Fixpoints.
> Interscript is based on that idea.

Just to be pedantic ;-)  A Tex or Latex build is not guaranteed to 
converge so you may not have a fixed point in the computation. They can 
oscillate and it may be necessary to slightly alter the source document 
to get things to settle down.

-Eric

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

Re: [Caml-list] Building large and portable projects

[sylvain.le-gall]

On Fri, Nov 21, 2003 at 09:05:22AM -0800, Jason Hickey wrote:
> Martin Jambon wrote:
> >Is there a convenient way to develop OCaml code, and be sure that 
> >this code will be configurable, compilable, installable and 
> >executable without changes, on any environment where OCaml is available?
> 
> We have been using omake to build several large projects, primarily on 
> Linux and Windows.  omake is written in OCaml, and provides a build 
> system with syntax similar to make, but project-wide dependency 
> analysis.  Here are some features:
> 
>     - omake runs on Unix, Windows, MacOS, and presumably
>       other architectures where OCaml is available.
>     - dependency analysis is project-wide (like cons),
>       based on MD5 digests
>     - automated dependency analysis
>     - there is builtin support for OCaml and C code,
>       and it is easy to add support for other kinds
>       of files (just like make).
>     - the OMakefile syntax is similar to GNU make, but
>         - omake has user-defined functions
>         - OMakefile programs are functional
>         - the .SUBDIRS target is used to define
>           the project hierarchy
>         - different parts of the project can have
>           different configuration.
> 
> omake is available by anonynous CVS from cvs.metaprl.org.
>    % cvs -d :pserver:anoncvs@cvs.metaprl.org:/cvsroot login
>    The password is anoncvs.
>    % cvs -d :pserver:anoncvs@cvs.metaprl.org:/cvsroot checkout omake
> 
> Alternatively, RPMs are available at rpm.nogin.org.
> 
> Here is a short description.  Every project must have an OMakeroot file 
> in the project root.  It is usually boilerplate; this is typical:
> 
>    # Include the standard configuration
>    include $(STDROOT)
> 
>    # Include the OMakefile
>    .SUBDIRS: .
> 
> The project commands are then placed in an OMakefile.  To build a 
> standalone OCaml program from files a.ml b.ml and c.ml, you just need 
> one line.  The OCamlProgram function is defined in the system OMakeroot.
> 
>    OCamlProgram(foo, a b c)
> 
> You can choose the byte-compiler, native-code compiler, or both.
> 
>    BYTE_ENABLED = true
>    NATIVE_ENABLED = true
>    OCamlProgram(foo, a b c)
> 
> Maybe you have some C files you need to include in your compile as well. 
>  Perhaps f.c is a generated file.
> 
>    f.c: f1.c f2.c
> 	cat $+ > $@
>    StaticCLibrary(bar, d e f)
>    LIBS = bar
>    OCamlProgram(foo, a b c)
> 
> Perhaps you use the C-preprocessor on some .mlp files:
> 
>    %.ml: %.mlp
> 	$(CPP) $*.mlp > $@
> 
> The system sources contain more examples, and the MetaPRL system, also 
> available at cvs.metaprl.org, provides a very large, complex, example.
> 
> Jason
> 
Hello,

It seems great to me...

Is there way to define camlp4 syntax ? ( for example XXX.ml needs camlp4
with cmo zoggy.cmo or something like that )

Is there a kind of configure in it ?

Can you use META files.

(... a lot of other question but i will take a look at it before asking
).

Kind regad
Sylvain LE GALL

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

Re: [Caml-list] Building large and portable projects

[sylvain.le-gall]

On Fri, Nov 21, 2003 at 05:32:50PM +0100, Martin Jambon wrote:
> On Fri, 21 Nov 2003 sylvain.le-gall@polytechnique.org wrote:
> 
> > My aims is to make something more Makefile like ( ie you will have the
> > ability to add rules ). Off course, my first goal is to compile ml file.
> > So there will be less features than Makefile.
> 
> Are you sure? If this compiles only Caml code, nobody will use it for 
> serious projects. But I was thinking of loadable modules like in emacs 
> instead of a rigid and limited set of predefined rules.
> If we think of make as a preprocessor for shell-scripts, then we can 
> create a preprocessor for OCaml that will do the same but will benefit 
> from many built-in properties that sh doesn't have and that (GNU) make 
> hardly provides.
> 

Hello,

I was thinking of dynlink for loadable module...

But i need to investigate on other tools ( omake ).

Regard
Sylvain LE GALL

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

Re: [Caml-list] Building large and portable projects

[sylvain.le-gall]

Hello,

On Sat, Nov 22, 2003 at 03:12:48AM +1100, skaller wrote:
> On Fri, 2003-11-21 at 17:49, sylvain.le-gall@polytechnique.org wrote:
> > On Fri, Nov 21, 2003 at 02:48:17PM +0900, Nicolas Cannasse wrote:
> 
> > On the other hand the aim will be to have a self contained tools ( ie
> > when you write a makefile you use rm, cp, touch
> > .. here the aims will be
> > to have it in ocaml ). So you could build on every platform which
> > support ocaml.
> 
> The goal is impossible. For example, all my Ocaml
> source is literate programmed. You surely aren't
> going to rewrite Interscript in Ocaml are you?
> 

Ok i have read your mail but i need time to understand all what is lying
in it.

I don't want to reproduce make bugs... I just want to do something
simple where you can type :

let my_prog = {
	name : "my_prog";
	compile_target : [Opt;Byte];
	toplevel_files : [ "my_prog.ml" ;
	"something_ocamldep_dont_recognize_as_toplevel.ml" ];
	package : "all_my_life" ;
	target_tag : Binary; ( or Documentation or Custom of string )
	}

let _ =
	add_target my_prog

Ie, it is not makefile syntax.

But, i don't really have begin my project... So i can't already said
that i will use this or that...

Kind regard
Sylvain LE GALL

ps : if you are interested, i will contact you when i will consider
enough mature to begin with this huge task ( in fact, i have made a kind
of start with the findlib branch of cameleon, but i am not finished ).
	

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

[Caml-list] Omake [Was: Building large and portable projects]

[Aleksey Nogin]

On 21.11.2003 10:55, sylvain.le-gall@polytechnique.org wrote:

> Is there way to define camlp4 syntax ? ( for example XXX.ml needs camlp4
> with cmo zoggy.cmo or something like that )

Yes, the syntax would be something like

if true
    OCAMLFLAGS += -pp "camlp4 zoggy.cmo"
    XXX.cmx XXX.o:
    XXX.cmo:

The idea is the following:
- variables inside the "if" statements are locally scope (unless you 
explicitly export the variable environment back to the parent scope), so 
we use the "if true" as a synonym for "local". So, the above tells omake 
to add a preprocessor flag to ocamlc/ocamlopt when compiling XXX.cmx, 
XXX.o and XXX.cmo.

Alternatively, you could define a helper macro:

UseCamlp4(modules, files) =
    OCAMLFLAGS += -pp "camlp4 $(addsuffix .cmo, $(modules))"
    $(addsuffix .cmx, $(modules)) $(addsuffix .o, $(modules)):
    $(addsuffix .cmo, $(modules)):

UseCamlp4(zoggy, XXX)

Actually, it might be a good idea to add such a macro to the global 
rules file included with omake - I filed 
http://cvs.metaprl.org:12000/bugzilla/show_bug.cgi?id=119 on this.

> Is there a kind of configure in it ?

There are a number of mechanisms for hooking to an external one. For 
example, you could specify dependencies and commands when including file as:


.INCLUDE: foo
    bla bla > foo

.INCLUDE: foo: foo.in
    bla bla bla bla < foo.in > foo

The above tell omake that
- it should include foo and if the file does not exist, it should use 
"bla bla" to generate it. Next, it should check whether foo is newer 
than foo.in and generate foo again (using "bla bla blah blah" this time) 
and then include it again.

You can also specify dependencies for the OMakefile itself:

if $(not $(equal $(OSTYPE), Win32))
     OMakefile: OMakefile.in config.status
    @echo "*** Build system is out-of-date, rebuilding ***"
    $(DOT)config.status
    @echo "*** OMakefile was rebuilt, session should restart ***"

> Can you use META files.

Not sure what those are.

On 21.11.2003 08:12, skaller wrote:

> But it is much worse. A target can
> depend on itself. Interscript assumes that.
> An example is a Latex build, which depends
> on auxilliary files generated by the build
> [Ocamldoc output can take 4 passes to fixate
> for example].

Well, we are hoping to support those in omake (still work in progress) - 
http://cvs.metaprl.org:12000/bugzilla/show_bug.cgi?id=86

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907

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

Re: [Caml-list] Omake [Was: Building large and portable projects]

[Damien]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

Why isn't this tool widely distributed/promoted !?

I looked quickly at it, and tried to use for a project I am currently
working on,

however my project uses "-pack" in order to pack some branches
(sub-directories) and avoid A_B_.._M module names.

looking at Omakeroot, it seems to me there is no support for things like
that :-( 
Has someone already managed to do it ? (if not, I'll try to do it by
myself)


To give an idea of what I would like to do :

a few weeks ago, I tried to do it with OCamlMakefile, and ended up with
the attached OMakefile (which works fine for me, but is no more easily
merge-able with OCamlMakefile, and has no support for non Unix systems)
to use it, just write your Makefile like this :

<<
SOURCES=a.ml p.pack b/o.ml b/o.mli d.glade
RESULT=k
include OMakefile
>>

where p.pack is a file containing the list of modules to pack into P :

<<
pa.ml
pl.lex
pq.pack
pr.ml
>>

(the latter files must reside in the directory "p/")

standard options of OCamlMakefile are also supported.


damien

[-- Attachment #2: OMakefile --]
[-- Type: application/octet-stream, Size: 9554 bytes --]

#
# Copyright (C) 2003 Damien Pous 
#  
#  This file is part of Mocambients.
#  
#  Mocambients is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#  
#  Mocambients is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#  
#  You should have received a copy of the GNU General Public License
#  along with Mocambients; if not, write to the Free Software
#  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#
# Generic Makefile for use with ocaml, 
#
#  partially derived from 
#    OCamlMakefile Copyright (C) 1999-2003 Markus Mottl
#  <http://www.oefai.at/~markus/ocaml_sources>
#  
# 
#
# Here is the list of the meaningful variables
#
# SOURCES : 	list of source files to compile
#           the following extensions are supported: 
#           - .mli   : ocaml interface
#           - .ml    : ocaml implementation
#           - .mll   : ocamllex lexer
#           - .mly   : ocamlyacc parser
#           - .rep   : cameleon report
#           - .zog   : cameleon zoggy
#           - .glade : glade project
#           - .pack  : pack file, ie a list source files residing in a directory
#                        the resulting objects will be packed into a single one
#
# RESULT : 	name of the executable/library to build
#
# INCDIRS : 	external directories for finding .cmi files
#
# LIBS : 	libraries to link with (don't put the suffix)
#
# TRASH : 	special files to remove when doing "make clean"
#
# OMAKEFILE : 	location of the OMakefile
#
# BYTECODE / NATIVE : 
#		set one of these variable to use the corresponding compilation mode
#
# QUIET : 	unset it to see every command achieved by make
#
# PROFILING : 	set it in order to activate profiling
#
# DEBUG : 	set it in order to activate debugging
#
# ANNOTATE : 	set it in order to create .annot files, for use with emacs/caml-types
#
# CUSTOM : 	set it in order to compile bytecode in custom mode
#
# USE_CAMLP4 : 	set it in order to use camlp4 with files beginning with (*pp ... *)
# 
# OCAMLC, OCAMLOPT, CAMLP4, OCAMLCP, OCAMLMKTOP, OCAMLDEP, OCAMLLEX, OCAMLYACC, 
# CAMELEON_REPORT, CAMELEON_ZOGGY, OCAML_GLADECC :
#		override these variables to use your own compilers, or specify 
#		special options



######################################################################
# non exported variables

ifndef SOURCES
  SOURCES := foo.ml
endif

ifndef RESULT
  RESULT := foo
endif

ifndef OCAMLC
  OCAMLC := ocamlc
endif

ifndef OCAMLOPT
  OCAMLOPT := ocamlopt
endif

ifndef OCAMLCP
  OCAMLCP := ocamlcp -p a
endif

ifndef OCAMLMKTOP
  OCAMLMKTOP := ocamlmktop
endif

ifdef PROFILING
  OCAMLC := $(OCAMLCP)
  OCAMLOPT += -p
endif

ifdef DEBUG
  OCAMLC += -g
  OCAMLOPT += -g
endif

ifdef ANNOTATE
  OCAMLC += -dtypes
  OCAMLOPT += -dtypes
endif

ifdef CUSTOM
  CUSTOM := -custom
endif


######################################################################
# exported variables (mainly for dependencies)

ifdef BYTECODE
  ifdef NATIVE
    OBC := $(origin BYTECODE)
    ONC := $(origin NATIVE)
    ifeq "$(OBC)" "$(ONC)"
      ARF := $(error: please choose bytecode OR native compilation)
    else
      ifeq "$(ONC)" "command line"
        NATIVE := yes
      else
	NATIVE := 
      endif
    endif
  endif
endif

ifndef OCAMLDEP
  OCAMLDEP := ocamldep
endif
ifdef NATIVE
  OCAMLDEP += -native
  DEP_EXTN = .xdepend
  CM_EXTN  = cmx
  LIB_EXTN = cmxa
else
  DEP_EXTN = .depend
  CM_EXTN  = cmo
  LIB_EXTN = cma
endif
export OCAMLDEP DEP_EXTN CM_EXTN NATIVE

ifndef OCAMLLEX
  OCAMLLEX := ocamllex
endif
export OCAMLLEX

ifndef OCAMLYACC
  OCAMLYACC := ocamlyacc
endif
export OCAMLYACC

ifndef CAMELEON_REPORT
  CAMELEON_REPORT := report
endif
export CAMELEON_REPORT

ifndef CAMELEON_ZOGGY
  CAMELEON_ZOGGY := camlp4o pa_zog.cma pr_o.cmo
endif
export CAMELEON_ZOGGY

ifndef OCAML_GLADECC
  OCAML_GLADECC := lablgladecc2
endif
export OCAML_GLADECC

ifndef CAMLP4
  CAMLP4 := camlp4
endif
export CAMLP4

ifdef USE_CAMLP4
  PP = $(shell sed -n -e '/^\#/d' -e 's/(\*pp \([^*]*\) \*)/-pp "\1"/p;q' $<)
else
  PP = 
endif
export USE_CAMLP4

ifndef OMAKEFILE
  OMAKEFILE := OMakefile
endif
export OMAKEFILE

QUIET = @
export QUIET


######################################################################
# source files / objects definitions

EXTNS        := %.mli %.ml %.mll %.mly %.rep %.zog %.glade %.pack
UNKNOWN      := $(filter-out $(EXTNS),$(SOURCES))
ERR          := $(if $(UNKNOWN),$(error Don\'t know how to compile $(UNKNOWN)),)

BDIR         := $(notdir $(PWD))

SOURCE_DIRS  += $(filter-out ./, $(sort $(dir $(SOURCES))))
DEP_INCLUDES := $(patsubst %,-I %,$(SOURCE_DIRS))
INCLUDES     := $(patsubst %,-I %,$(INCDIRS)) $(DEP_INCLUDES)
export SOURCE_DIRS

SOURCES_ML   := $(filter %.ml, $(SOURCES))

SOURCES_MLI  := $(filter %.mli, $(SOURCES))

SOURCES_MLL  := $(filter %.mll, $(SOURCES))
AUTO_MLL     := $(SOURCES_MLL:.mll=.ml)

SOURCES_MLY  := $(filter %.mly, $(SOURCES))
AUTO_MLY     := $(SOURCES_MLY:.mly=.mli) $(SOURCES_MLY:.mly=.ml)

FILTERED_REP := $(filter %.rep, $(FILTERED))
AUTO_REP     := $(FILTERED_REP:.rep=.ml)

FILTERED_ZOG := $(filter %.zog, $(FILTERED))
AUTO_ZOG     := $(FILTERED_ZOG:.zog=.ml)

SOURCES_GLADE:= $(filter %.glade, $(SOURCES))
AUTO_GLADE   := $(SOURCES_GLADE:.glade=.ml)

SOURCES_PACK := $(filter %.pack, $(SOURCES))
AUTO_PACK    := $(SOURCES_PACK:.pack=.mli)
PACKAGE_DIRS := $(AUTO_PACK:.ml=/)
TRASH        += $(AUTO_PACK)

PRE_TARGETS  += $(AUTO_MLL) $(AUTO_MLY) $(AUTO_REP) $(AUTO_ZOG) $(AUTO_GLADE)

OBJECTS      := $(addsuffix .cmo,$(basename $(filter-out %.mli,$(SOURCES))))
OBJECTS_OPT  := $(OBJECTS:.cmo=.cmx)
OBJECTS_DEP  := $(foreach f, $(SOURCES_ML) $(SOURCES_MLI) $(SOURCES_PACK) $(AUTO_MLL) $(AUTO_MLY) $(AUTO_REP) $(AUTO_ZOG) $(AUTO_GLADE),$(DEP_EXTN).d/$(f)$(DEP_EXTN))
TRASH        += $(OBJECTS) $(OBJECTS_OPT) $(OBJECTS:.cmo=.o) $(OBJECTS:.cmo=.cmi) $(OBJECTS:.cmo=.annot)


getmodules   = $(addprefix $(3),$(addsuffix .$(2),$(basename $(filter-out %.mli,$(shell cat $(1))))))
getdirs_     = $(if $(findstring $(1),./),,$(1) $(call getdirs,$(1:/=)))
getdirs      = $(call getdirs_,$(dir $(1)))
getsources   = $(addprefix $(1:.pack=)/,$(shell cat $(1)))
ALL_INCLUDES = $(INCLUDES) $(patsubst %,-I %,$(call getdirs,$<))


ifdef NATIVE
  OCAMLMODE   = $(OCAMLOPT)
  OBJECTSMODE =	$(OBJECTS_OPT)
  CUSTOM      =
else
  OCAMLMODE   = $(OCAMLC)
  OBJECTSMODE =	$(OBJECTS)
endif
LIBSMODE    = $(addsuffix .$(LIB_EXTN),$(LIBS))


.FORCE: 

######################################################################
# Rules

%.ml :		%.mll
	$(OCAMLLEX) $<

%.ml %.mli :	%.mly
	$(OCAMLYACC) $<

%.ml :		%.rep
	$(CAMELEON_REPORT) -gen $<

%.ml :		%.zog
	$(CAMELEON_ZOGGY) -impl $< > $@

%.ml :		%.glade
	$(OCAML_GLADECC) $< > $@

%.cmi : %.pack
	$(QUIET)true

%.$(CM_EXTN) : %.pack
	$(OCAMLMODE) -pack -o $@ $(ALL_INCLUDES) -I $(<:.pack=) $(call getmodules,$<,$(CM_EXTN))

%.cmi :		%.mli
	$(OCAMLMODE) $(PP) -c $(ALL_INCLUDES) $<

%.$(CM_EXTN) :	%.ml
	$(OCAMLMODE) $(PP) -c $(ALL_INCLUDES) $<


######################################################################
# Dependencies 

.PHONY: .autopacks
.autopacks:
	$(QUIET)for i in $(AUTO_PACK); do echo "(* dummy auto-generated file, don't edit *)" > $$i; done

ifndef DEPEND
  DEPEND := $(DEP_EXTN)
endif

$(DEP_EXTN).d/%.pack$(DEP_EXTN) : %.pack %/
	@echo make[_]: Entering directory $(basename $<)
	$(QUIET)$(MAKE) --no-print-directory -f $(OMAKEFILE) dep \
		DEPEND=$@ SOURCES="$(call getsources,$<)"
	@echo make[_]: Leaving directory $(basename $<)

$(DEP_EXTN).d/%$(DEP_EXTN) : %
	$(QUIET)mkdir -p $(dir $@)
	$(OCAMLDEP) $(DEP_INCLUDES) $< > $@

.PHONY : dep
dep : $(DEPEND)

$(DEPEND) : .autopacks $(PRE_TARGETS) $(OBJECTS_DEP)
	$(QUIET)mkdir -p $(dir $@)
	$(QUIET)cat $(OBJECTS_DEP) > $@
ifdef SOURCES_PACK
	$(QUIET)echo -e $(foreach p,$(SOURCES_PACK),\
\\n$(p:.pack=.$(CM_EXTN)): $(call getmodules,$(p),$(CM_EXTN),$(p:.pack=/))\
\\n$(p:.pack=.cmi): $(p:.pack=.$(CM_EXTN))) >> $@
	$(QUIET)rm -f $(AUTO_PACK)
endif


######################################################################
# Housekeeping

%.clean : %.pack .FORCE
	@echo make[_]: Entering directory $(basename $<)
	$(QUIET)$(MAKE) --no-print-directory -f $(OMAKEFILE) clean \
		SOURCES="$(call getsources,$<)" 
	@echo make[_]: Leaving directory $(basename $<)

clean : $(SOURCES_PACK:.pack=.clean) cleanup .FORCE
	rm -f $(RESULT) $(RESULT).cma $(RESULT).cmxa $(RESULT).top

cleanup : .FORCE
	rm -rf .depend .xdepend .depend.d/ .xdepend.d/
	rm -f $(PRE_TARGETS) $(TRASH)

nobackup : 
	find . -name '*~' -o -name '*.bak' | xargs rm -f

bz2 : clean nobackup
	tar cjf ../$(BDIR)_$(shell date +%F).tar.bz2 -C .. $(BDIR)

gz : clean nobackup
	tar czf ../$(BDIR)_$(shell date +%F).tar.gz -C .. $(BDIR)


######################################################################
# Final targets

all: $(RESULT)
$(RESULT) : $(OBJECTSMODE)
	$(OCAMLMODE) $(CUSTOM) -o $@ $(INCLUDES) $(LIBSMODE) $^

nl no-link: $(OBJECTSMODE) 

lib: $(RESULT).$(LIB_EXTN)
$(RESULT).$(LIB_EXTN): $(OBJECTSMODE)
	$(OCAMLMODE) -a -o $@ $(INCLUDES) $(LIBSMODE) $^

top: $(RESULT).top
ifndef NATIVE
$(RESULT).top : $(OBJECTSMODE)
	$(OCAMLMKTOP) -o $@ $(INCLUDES) $(LIBSMODE) $^
else
$(RESULT).top : 
	$(error Cannot create a toplevel in native mode)
endif



-include $(DEP_EXTN)

Re: [Caml-list] Omake [Was: Building large and portable projects]

[sylvain.le-gall]

Hello, again

On Fri, Nov 21, 2003 at 11:30:29AM -0800, Aleksey Nogin wrote:
> On 21.11.2003 10:55, sylvain.le-gall@polytechnique.org wrote:
> 
> >Is there way to define camlp4 syntax ? ( for example XXX.ml needs camlp4
> >with cmo zoggy.cmo or something like that )
> 
> Yes, the syntax would be something like
> 
> if true
>    OCAMLFLAGS += -pp "camlp4 zoggy.cmo"
>    XXX.cmx XXX.o:
>    XXX.cmo:
> 
> The idea is the following:
> - variables inside the "if" statements are locally scope (unless you 
> explicitly export the variable environment back to the parent scope), so 
> we use the "if true" as a synonym for "local". So, the above tells omake 
> to add a preprocessor flag to ocamlc/ocamlopt when compiling XXX.cmx, 
> XXX.o and XXX.cmo.
> 
> Alternatively, you could define a helper macro:
> 
> UseCamlp4(modules, files) =
>    OCAMLFLAGS += -pp "camlp4 $(addsuffix .cmo, $(modules))"
>    $(addsuffix .cmx, $(modules)) $(addsuffix .o, $(modules)):
>    $(addsuffix .cmo, $(modules)):
> 
> UseCamlp4(zoggy, XXX)
> 
> Actually, it might be a good idea to add such a macro to the global 
> rules file included with omake - I filed 
> http://cvs.metaprl.org:12000/bugzilla/show_bug.cgi?id=119 on this.
> 
> >Is there a kind of configure in it ?
> 
> There are a number of mechanisms for hooking to an external one. For 
> example, you could specify dependencies and commands when including file as:
> 
> 
> .INCLUDE: foo
>    bla bla > foo
> 
> .INCLUDE: foo: foo.in
>    bla bla bla bla < foo.in > foo
> 

Ok. But i am looking for something included in it ( think that in your
very large project, you have a library that builds against an external
one, i want that the makefile system detect it and output that it needs
this library... ).

> 
> if $(not $(equal $(OSTYPE), Win32))
>     OMakefile: OMakefile.in config.status
>    @echo "*** Build system is out-of-date, rebuilding ***"
>    $(DOT)config.status
>    @echo "*** OMakefile was rebuilt, session should restart ***"

In fact i want to get rid of it ( no $(DOT)config.status ). Autools et
al are very well made but i think that it is too much complicated (
having try to understand how it is build but most of the time i really
can t get into it ).

> 
> >Can you use META files.
> 
> Not sure what those are.
> 

META file comes with findlib. Findlib is an helper to configure ocaml
compilation :
ocamlfind ocamlc -package "fileutils" xxx.ml 
will run ocamlc -I /usr/lib/ocaml/fileutils ...

Gerd Stolpmann write it ( www.ocaml-programming.de ). Sorry to the
author if i mistyped his name...

I take a quick glance to you OMakefile...

Well i think it is very powerfull and very interesting... But ( there is
always a but ), i am looking for something between your very complete
suite and ocamake which is light and permits to do fast job for ocaml
stuff. 

I know, i will run into problem if not targeting all people... But, i
cannot choose all options. I want something enough powerfull to build
little to medium ocaml project -- with some C binding. I don't want to
rebuild make. The ideal project ( in size ) will be cameleon ( fully
written in ocaml ) or mldonkey ( mostly ocaml with some C ). I don't
really want to be able to compile C, python, Ada...

I want to use some kind of ocaml script ( let say makefile.ml which will
contain the instruction to build, explains the dependency etc ) to
enable user to be fully consistent with their project ( they learn ocaml
and not makefile syntax ). I think it should be necessary to have a
plugin system ( through dynlink or topfind, don't know yet ) to enable them 
to develop their own set of rules ( if they want to compile specific
things ).

What i have read in you omakefile is a kind of full rewrite of make ( ie
you have construct of function, dependency etc ). I precisely don't want 
to develop my own langage for this purpose, i want to have it written in
ocaml.

Just to give you an example, all the student i know have problem using
makefile because they don't want to spend two hours understanding this
big script... So they simply don't use it... How many times i have seen
one-file-project without makefile, or people using "ocamlc X.ml &&
ocamlc Y.ml && ocamlc Z.ml..."

I want ( just as i have posted before ) :

let my_prog = { name = "my_prog";...;toplevels = [ "X.ml" ] }
in
add_target my_prog

and that's all. And i want to be able to do it on linux or win without
being needed to do if Win32 then ... else ... ( every time you write if
... else ..., it is a possible infinite source of error ).

I will have a deeper look to your omakefile ( understanding how it is
working, if i can learn from the rules to target process ... ). 

thanks for having helped me to find more project similar to mine.

Kind regard
Sylvain LE GALL

ps : i cannot find your project omakefile on humps
pps : if you have time you could take a look at cameleon CVS, branch
findlib : http://savannah.nongnu.org/projects/cameleon, there is a bunc
of ten lines makefile which are sufficient to define what to compile for
each directory... That is the mininum sums of information i want user to
give to have a fully working makefile system

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

Re: [Caml-list] Omake [Was: Building large and portable projects]

[Nicolas Cannasse]

From: <sylvain.le-gall@polytechnique.org>
[...]
> Well i think it is very powerfull and very interesting... But ( there is
> always a but ), i am looking for something between your very complete
> suite and ocamake which is light and permits to do fast job for ocaml
> stuff.
>
> I know, i will run into problem if not targeting all people... But, i
> cannot choose all options. I want something enough powerfull to build
> little to medium ocaml project -- with some C binding. I don't want to
> rebuild make. The ideal project ( in size ) will be cameleon ( fully
> written in ocaml ) or mldonkey ( mostly ocaml with some C ). I don't
> really want to be able to compile C, python, Ada...
>
> I want to use some kind of ocaml script ( let say makefile.ml which will
> contain the instruction to build, explains the dependency etc ) to
> enable user to be fully consistent with their project ( they learn ocaml
> and not makefile syntax ). I think it should be necessary to have a
> plugin system ( through dynlink or topfind, don't know yet ) to enable
them
> to develop their own set of rules ( if they want to compile specific
> things ).

I definitly thinks that such a thing could use OCamake. As I told before,
adding C bindings compilation might be easy but require some fixes. For
other operations (file rename, copy, auto install, etc... ) we can provide
them in another module. I agree to work on that with you if you want (french
language will help ^^).

[...]
> Just to give you an example, all the student i know have problem using
> makefile because they don't want to spend two hours understanding this
> big script... So they simply don't use it... How many times i have seen
> one-file-project without makefile, or people using "ocamlc X.ml &&
> ocamlc Y.ml && ocamlc Z.ml..."

That's precisely why I wrote OCamake...

> I want ( just as i have posted before ) :
>
> let my_prog = { name = "my_prog";...;toplevels = [ "X.ml" ] }
> in
> add_target my_prog
>
> and that's all. And i want to be able to do it on linux or win without
> being needed to do if Win32 then ... else ... ( every time you write if
> ... else ..., it is a possible infinite source of error ).

Of course :)

Nicolas Cannasse

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

Re: [Caml-list] Omake [Was: Building large and portable projects]

[Aleksey Nogin]

On 21.11.2003 12:39, Damien wrote:

> I looked quickly at it, and tried to use for a project I am currently
> working on,
> 
> however my project uses "-pack" in order to pack some branches
> (sub-directories) and avoid A_B_.._M module names.
> 
> looking at Omakeroot, it seems to me there is no support for things like
> that :-( 
> Has someone already managed to do it ? 

Didn't have time to write more about this earlier today, but it should 
be very simple. The following macro will probably work (haven't tested 
it myself)

OcamlPack(dst, sources) =
    if $(and $(NATIVE_ENABLED) $(BYTECODE_ENABLED))
       $(dst).cmo $(dst).cmx $(dst).cmi $(dst).o: $(addsuffix .cmo, 
$(sources)) $(addsuffix .cmx, $(sources)) $(addsuffix .o, $(sources)) 
$(addsuffix .cmi, $(sources))
          $(OCAMLOPT) $(OCAMLOPTFLAGS) -pack -o $(dst).cmx $(addsuffix 
.cmx, $(sources))
          $(OCAMLC) $(OCAMLCFLAGS)-pack -o $(dst).cmo $(addsuffix .cmo, 
$(sources))
    else
       $(dst).cmo $(dst).cmi : $(addsuffix .cmo, $(sources)) $(addsuffix 
.cmi, $(sources))
          $(OCAMLC) $(OCAMLCFLAGS)-pack -o $(dst).cmo $(addsuffix .cmo, 
$(sources))

       $(dst).cmx $(dst).cmi $(dst).o: $(addsuffix .cmx, $(sources)) 
$(addsuffix .o, $(sources)) $(addsuffix .cmi, $(sources))
          $(OCAMLOPT) $(OCAMLOPTFLAGS) -pack -o $(dst).cmx $(addsuffix 
.cmx, $(sources))

And then just invoke it using

OcamlPack(foo, bar1 bar2 bar3 ... )

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907

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

Re: [Caml-list] Omake [Was: Building large and portable projects]

[Aleksey Nogin]

On 21.11.2003 15:48, sylvain.le-gall@polytechnique.org wrote:

> Ok. But i am looking for something included in it ( think that in your
> very large project, you have a library that builds against an external
> one, i want that the makefile system detect it and output that it needs
> this library... ).

Well, included is a macro language that should (ideally) allow you to 
define things you want. If needed, you can relatively easily extend the 
language of built-in functions as well (which means you have to change 
omake source code, but it gives you access to full OCaml).

> META file comes with findlib. Findlib is an helper to configure ocaml
> compilation :
> ocamlfind ocamlc -package "fileutils" xxx.ml 
> will run ocamlc -I /usr/lib/ocaml/fileutils ...

[...]

> I want ( just as i have posted before ) :
> 
> let my_prog = { name = "my_prog";...;toplevels = [ "X.ml" ] }
> in
> add_target my_prog

Well, does it really have to be written in OCaml?

Note that if one would want to use omake for simple projects, all that 
[s]he would have to learn is couple of macros (which completely hide the 
notions of "target", "dependency", etc) and couple of standard 
variables. E.g, you'd need couple of line for the project:

OCAMLC = ocamlfind ocamlc -package "fileutils"
OCamlProgram(my_prog, X Y Z ...)

Note that the standard macros are not in any way built-in (the way make 
has a big number of built-in rule), they just come from an include file 
(that can be studied and even modified if a small simple project ends up 
growing into a large and complicated one).

Note - if in the example above you do not want to rely on external 
ocamlfind, you could add ocamlfind code to omake, changing the above to

OCAMLINCLUDES += $(ocamlfind fileutils)
OCamlProgram(my_prog, X Y Z ...)

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907

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

Re: [Caml-list] Building large and portable projects

[Martin Berger]

> Make systems are all conceptually wrong.

agreed.

> This leads to the first novel idea. Fixpoints.
> Interscript is based on that idea.

> A build system does NOT have targets. 

> A build systems has processes and files.
> Lets call the processes ARROWS and the files OBJECTS.

> Oh. That's a category. We allow of course,
> products of files (multiple outputs and inputs)
> and sums of files (choose one of several).
> [And of course we'd better make it cartesian
> closed and allow processes to be files .. 
> called scripts .. :]

this is a fascinating proposal. i have two immediate questions:

* as someone else pointed out, relying on convergence towards
   fixpoints may be too strong. some build processes may
   never converge, rather they evenually stabilise in some
   "open ball", so you might need some (user supplied) notion
   of "close enough". how do you do that?

* according to [1], a cartesian closed category with fixpoints
   and finite sums is equivalent to the category with one object
   and one arrow. how do you deal with this?

martin

[1] Hagen Huwig and Axel Poigne, A note on inconsistencies caused
by fixpoints in a cartesian dosed category, Theoretical Computer
Science 73 (1990), p. 101-112.

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

Re: [Caml-list] Building large and portable projects

[skaller]

On Sat, 2003-11-22 at 06:04, sylvain.le-gall@polytechnique.org wrote:

> I don't want to reproduce make bugs... I just want to do something
> simple where you can type :
> 
> let my_prog = {
> 	name : "my_prog";
> 	compile_target : [Opt;Byte];
> 	toplevel_files : [ "my_prog.ml" ;
> 	"something_ocamldep_dont_recognize_as_toplevel.ml" ];
> 	package : "all_my_life" ;
> 	target_tag : Binary; ( or Documentation or Custom of string )
> 	}
> 
> let _ =
> 	add_target my_prog
> 
> Ie, it is not makefile syntax.

My guess is that the 'object oriented design
paradigm' has something to say here -- 
do it bottom up. The first step is to define
things like

	compare_time_stamp(f1, f2)

a module for 'dependency graph', and
other tools that may be useful.

Then just write plain Ocaml code using these tools.

This may be a bit long winded, so check out camlp4
to sweeten it up.

The advantage of this approach is that a make script
is an arbitrary caml script.

Which means: it can do anything easily (since caml
is so expressive), it is also type checked (hey,
why shouldn't build scripts be type checked?)

etc etc etc ...

Finally after all that if you still think a language
translator is needed to express the build conditions
above and beyond caml with camlp4 ... then one
can be written, plugged into the front, invoked
by the caml build script, compiled and executed ..
all without requiring ME or anyone else
to use your language (you can just embed the
translator in your package).

This is basically what interscript does only
its hooks Python and it's aimed at packaging
software components (meaning source codes and
documentation) in a more general fashion
than merely building them would require.
It actually has a language translator,
but it's a pretty brain dead one that basically
allows code, doco, and executable script to be
mixed together in a single source file.


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

Re: [Caml-list] Building large and portable projects

[skaller]

On Sat, 2003-11-22 at 04:53, Eric Dahlman wrote:
> skaller wrote:
> 
> > But it is much worse. A target can
> > depend on itself. Interscript assumes that.
> > An example is a Latex build, which depends
> > on auxilliary files generated by the build
> > [Ocamldoc output can take 4 passes to fixate
> > for example].
> > 
> > This leads to the first novel idea. Fixpoints.
> > Interscript is based on that idea.
> 
> Just to be pedantic ;-)  A Tex or Latex build is not guaranteed to 
> converge so you may not have a fixed point in the computation. They can 
> oscillate and it may be necessary to slightly alter the source document 
> to get things to settle down.

If I may also be pedantic: this is not a matter of pedantry :-)

The idea of fixpoints is still novel and useful here.
As you comment, oscillations are possible. Divergence
is also possible. Interscript has a command line like

	iscr --passes=4 other options ...

which limits the number of passes. The default is one
pass, but it has a persistence mechanism (Python marshal),
so that executing the command 4 times is roughly equivalent
to a single invocation with --passes=4, except that with
the --passes=4 option 1 to 4 passes are executed.

Interscript is also Make friendly -- if it writes the
same as a files contents the timestamps are not changed.
[Which is how it detects convergence :-]

It *also* has dependency checking which can detect
that a pass would be the same as the last pass and
so it is possible that 0 passes are executed.

The design is not particularly efficient, however
it handles things like: you can read a file that
doesn't exist, and later write it. No problem.
The error on the first pass is ignored. The file
is there on the second pass .. although it might
not fix.

BTW: there is a fun caveat. The one thing that
you must be careful NOT to ever do in Interscript
is put the code generation time directly into the generated
code -- that guarrantees divergence :-)


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

Re: [Caml-list] Building large and portable projects

[skaller]

On Sun, 2003-11-23 at 01:32, Martin Berger wrote:
> > Make systems are all conceptually wrong.

> * as someone else pointed out, relying on convergence towards
>    fixpoints may be too strong. some build processes may
>    never converge, rather they evenually stabilise in some
>    "open ball", so you might need some (user supplied) notion
>    of "close enough". how do you do that?

In interscript I have an iteration limit.
In a GUI system, one pass per mouse click I guess.

> * according to [1], a cartesian closed category with fixpoints
>    and finite sums is equivalent to the category with one object
>    and one arrow. how do you deal with this?
> 
> martin
> 
> [1] Hagen Huwig and Axel Poigne, A note on inconsistencies caused
> by fixpoints in a cartesian dosed category, Theoretical Computer
> Science 73 (1990), p. 101-112.

Ouch. First, the concept above is to use categories
as an inspirational model, but we do have to layer
the abstraction on real storage/execution systems,
so that theoretical constraint is unlikely to the most
difficult problem :-)

Second .. well, Ocaml uses this model 'as inspiration'
as well, and it's authors know a good deal more theory
than me so they're more likely to be able to answer :-)

Yeah, both answers are a cop-out (meaning I don't know :-)


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

Re: [Caml-list] Building large and portable projects

[skaller]

On Sun, 2003-11-23 at 04:08, David Brown wrote:
> On Sat, Nov 22, 2003 at 03:12:48AM +1100, skaller wrote:
> 
> > For example .c -cc--> .o -link--> exe, we can 
> > use the cached .o instead of running cc on the
> > .c provided the .c is older.
> 
> Older is incorrect, as well.  The program should run cc on the .c
> provided that the .c is different than the one used to produce the .o.
> Timestamps are useful as a cache, but a proper tool will need to use
> file hashes, or something to properly detect a file changing.

Yeah, that's a good point.

> An unrelated annoyance I've found is that ocamlc doesn't allow for the
> objects to be stored in a separate directory from this source.  This
> makes things, such as multiple configurations, multiple targets
> difficult.  Since ocamlopt doesn't currently support cross compilation,
> anyway, this is less of an issue.

It is still an issue if you have multiple Ocaml installations:
I actually ought to have 3 of them:

(a) the standard one my Linux came with
(b) the lastest release
(c) the CVS version

I need (a) to run system scripts (/usr)
I need (b) to check my code runs for clients (/usr/local),
and I need (c) cause I love playing with Ocaml :-)))

In addition I have to build my software at least in both
binary and bytecode form to check clients on
non-Linux platforms have some chance of using my product
if they can't get a native code compiler.

And then, there are versions of third party libraries ... ouch.

I have a starting concept here: I call it 'mount points'.
And another called 'mount stacks'.

A mount point is a root, specified as an OS native
directrory name. Files and directories down from
the mount point are always specified using Unix
convention (no matter what platform).

Then we have stacks. We start at the top mount
point of the stack and look for a file, going
down until we find it. However we always write
on the bottom. Here is a stack:

	/usr/lib/ocaml
	/usr/local/lib/ocaml
	/home/skaller/ocaml

The idea is you had hide *some* files
with an updated file, but don't need to
hide them all with a completely new distribution.
[A variant would just use patch files]

Additionally, writes (of object files etc) are
always most local and so don't interfere with
administrator installed compiled versions.

Another key part of it is relative file lookups.
The relativity is to a directory stack NOT
a particular directory so eg C #include "foo.h"
inside the file "bar.h" will follow the same
stack search algorithm except it will look
in the mount point of the stack + the subdirectory
of the file "bar.h".

A path is a sequence of stacks of mount points.

[It is also worth studying Kpathsea here ..]


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

Re: [Caml-list] Building large and portable projects

[David Brown]

On Sat, Nov 22, 2003 at 03:12:48AM +1100, skaller wrote:

> For example .c -cc--> .o -link--> exe, we can 
> use the cached .o instead of running cc on the
> .c provided the .c is older.

Older is incorrect, as well.  The program should run cc on the .c
provided that the .c is different than the one used to produce the .o.
Timestamps are useful as a cache, but a proper tool will need to use
file hashes, or something to properly detect a file changing.

An unrelated annoyance I've found is that ocamlc doesn't allow for the
objects to be stored in a separate directory from this source.  This
makes things, such as multiple configurations, multiple targets
difficult.  Since ocamlopt doesn't currently support cross compilation,
anyway, this is less of an issue.

Dave

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

Re: [Caml-list] Building large and portable projects

[David Brown]

On Sat, Nov 22, 2003 at 03:12:48AM +1100, skaller wrote:

> First observe that building a system
> is a process where it is not always
> possible to determine the full sequence
> of commands in advance. Sometimes,
> you have to perform some action before
> you can decide what to do next.

Make doesn't try to determine everything in advance.  Well, sorta :-)
It does try to figure everything out in advance, and then sometimes
looks to see if that needs to change.  It makes it work in a few
situations where it wouldn't before.

A while back, I build something like ocamake that let you specify a
command like:

  myomake -o target a b c

This would compile modules a, b, and c, and any that they depended on.
They would be linked in an order that would link.  If you need more
control, you can specify additional modules on the command line.  This
kind of tool is useful for many projects.

Once I discovered not to try and figure everything out in advance, the
tool not only became easier to write, but possible.

Once other stuff is brought in (C, literate programming), the
specification needs to be more complex.

Dave

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

Re: [Caml-list] Building large and portable projects

[sylvain.le-gall]

On Sun, Nov 23, 2003 at 01:34:22AM +1100, skaller wrote:
> On Sat, 2003-11-22 at 06:04, sylvain.le-gall@polytechnique.org wrote:
> 
> > I don't want to reproduce make bugs... I just want to do something
> > simple where you can type :
> > 
> > let my_prog = {
> > 	name : "my_prog";
> > 	compile_target : [Opt;Byte];
> > 	toplevel_files : [ "my_prog.ml" ;
> > 	"something_ocamldep_dont_recognize_as_toplevel.ml" ];
> > 	package : "all_my_life" ;
> > 	target_tag : Binary; ( or Documentation or Custom of string )
> > 	}
> > 
> > let _ =
> > 	add_target my_prog
> > 
> > Ie, it is not makefile syntax.
> 
> My guess is that the 'object oriented design
> paradigm' has something to say here -- 
> do it bottom up. The first step is to define
> things like
> 
> 	compare_time_stamp(f1, f2)
> 
> a module for 'dependency graph', and
> other tools that may be useful.

Yeah, you are right, i was just showing you the final step... Ie what
the user will have to write to compile...

I don't want to specify a full language schemes... Too much complicated.
I just want to make it in ocaml in order to ease ocaml user to write
ocaml script to compile ocaml ( i repeat a lot of time ocaml because i
still think that it is enough expressive to describe a makefile process
and i don't want people to learn 10 language to create : a configure.in,
a Makefile.am... ). 
> 
> Then just write plain Ocaml code using these tools.
> 
> This may be a bit long winded, so check out camlp4
> to sweeten it up.
> 
> The advantage of this approach is that a make script
> is an arbitrary caml script.
> 
> Which means: it can do anything easily (since caml
> is so expressive), it is also type checked (hey,
> why shouldn't build scripts be type checked?)
> 
> etc etc etc ...
> 
> Finally after all that if you still think a language
> translator is needed to express the build conditions
> above and beyond caml with camlp4 ... then one
> can be written, plugged into the front, invoked
> by the caml build script, compiled and executed ..
> all without requiring ME or anyone else
> to use your language (you can just embed the
> translator in your package).
> 
> This is basically what interscript does only
> its hooks Python and it's aimed at packaging
> software components (meaning source codes and
> documentation) in a more general fashion
> than merely building them would require.
> It actually has a language translator,
> but it's a pretty brain dead one that basically
> allows code, doco, and executable script to be
> mixed together in a single source file.
> 
Maybe i miss one step : where can i found interscript ( i am not an
expert, i am sorry ).

thanks
Regard
Sylvain LE GALL

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

Re: [Caml-list] Building large and portable projects

[Nicolas Cannasse]

> > For example .c -cc--> .o -link--> exe, we can
> > use the cached .o instead of running cc on the
> > .c provided the .c is older.
>
> Older is incorrect, as well.  The program should run cc on the .c
> provided that the .c is different than the one used to produce the .o.
> Timestamps are useful as a cache, but a proper tool will need to use
> file hashes, or something to properly detect a file changing.

That's true doing a hashing is nice for C, but ocaml compilation is fast
enough so maybe the time difference between making the hash and compiling is
not so big. Another issue is storing the hashing in a temp file, while you
can compare directly time stamps of the object with the source. Actually the
only case were hashing is useful compare to timestamps is when a file is
only touched ( am I wrong ? ). This is not an average case, and when it's
happening juste compiling only this file (without a bunch of .h) seems fast
enough.

Nicolas Cannasse

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

Re: [Caml-list] Building large and portable projects

[David Brown]

On Sun, Nov 23, 2003 at 12:25:13PM +0900, Nicolas Cannasse wrote:

> > Older is incorrect, as well.  The program should run cc on the .c
> 
> That's true doing a hashing is nice for C, but ocaml compilation is fast
> enough so maybe the time difference between making the hash and compiling is
> not so big. Another issue is storing the hashing in a temp file, while you

Saying "older" is wrong not because it just compiles too often, but
because it also doesn't compile things it should.  Think of someone
moving files around without changing timestamps, and then putting the
old files back.  Normal make won't recompile them.

It is better to comile when you shouldn't than it is to not compile when
you need to.

And compiling ocaml isn't always fast.  The code I'm working on doesn't
compile the ocaml code any faster than the C code.

Dave

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

Re: [Caml-list] Building large and portable projects

[skaller]

On Sun, 2003-11-23 at 14:25, Nicolas Cannasse wrote:

> That's true doing a hashing is nice for C, but ocaml compilation is fast
> enough so maybe the time difference between making the hash and compiling is
> not so big. Another issue is storing the hashing in a temp file, while you
> can compare directly time stamps of the object with the source. Actually the
> only case were hashing is useful compare to timestamps is when a file is
> only touched ( am I wrong ? ). This is not an average case, and when it's
> happening juste compiling only this file (without a bunch of .h) seems fast
> enough.

Perhaps we should create a Sourceforge project?
Or add a new CVS module to ExtLib project?

BTW: one use of hashing is a language specific
*content* hash. This is something that can ignore
whitespaces and comments for example.

For C and C++, the compiler is slow and hashing
could be worth it.

For Ocaml, the compiler is fast BUT there is
a strict ordering requirement not present
in C which means a file close to the "start"
of a dependency graph is worth hashing to avoid
recompiling not just that file .. but all the
others after it: Ocaml separate compilation isn't
quite as 'separate' as C's :-)


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

Re: [Caml-list] Building large and portable projects

[Ken Rose]

skaller wrote:

<lots of stuff, which I've only read quickly.>

Perhaps you should take a look at Vesta (www.vestasys.org)  It uses a 
functional language to describe how to build a system, uses hashes to 
determine file equality, and caches derived files for reuse.  IT  seems 
to be the result of some very bright people sitting down at a blank 
piece of paper and designing a build management system.

  - ken


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

Re: [Caml-list] Building large and portable projects

[Christian Lindig]

On Mon, Nov 24, 2003 at 10:02:34AM -0800, Ken Rose wrote:
> skaller wrote:
> Perhaps you should take a look at Vesta (www.vestasys.org)  It uses a 
> functional language to describe how to build a system, uses hashes to 
> determine file equality, and caches derived files for reuse.  

In Vesta, your file system is part of the build system; when you execute
commands, it observes, which files in the file system it reads or
writes. While this ensures that Vesta really knows what files you depend
on, down to system libraries, it requires quite a setup.

-- Christian

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

Re: [Caml-list] Building large and portable projects

[David Brown]

On Fri, Nov 21, 2003 at 09:05:22AM -0800, Jason Hickey wrote:

> We have been using omake to build several large projects, primarily on 
> Linux and Windows.  omake is written in OCaml, and provides a build 
> system with syntax similar to make, but project-wide dependency 
> analysis.  Here are some features:

Is there a place to discuss omake?

Specifically, my question: is there something like the GNU Make 'shell'
function?  What I'm trying to do is use the output of 'ocamlc -where' in
a variable.  I need to run extract_crc as part of my build, and ocamlc
-where is a nice portable way of finding this directory.

Thanks,
Dave

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