Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Announcing the OMake build system version 0.9.1
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Marcin 'Qrczak' Kowalczyk <qrczak@k...>
Subject: Re: [Caml-list] Announcing the OMake build system version 0.9.1
skaller <skaller@users.sourceforge.net> writes:

> For interscript itself, the answer is no: it automatically extracts
> all sources no matter what you change.
>
> No dependency information is required, and no targets,
> and no makefile.

My makefiles generally include the following types of information:

- Rules which tell "how to compile a *.foo file into a *.bar file"
  and compiler options.

- Variable definitions which gather sources from contents of
  directories. It's usually "all files with a particular extension
  from subdirectories, plus some additions which are generated,
  minus some exceptions which are conditionally excluded".

- Rules which tell which sources and commands to use for many-to-one
  targets like programs and libraries, where source names are not
  derived from target names automatically because there are many
  sources.

- Administrative rules for things like "make clean" and "make install".

All this information is essential for building and impossible to infer
automatically from other files. Another build tool can't eliminate the
need of providing that information in some form. It can only provide a
different language for expressing it.

Dependencies between the source of module Foo which uses module Bar,
and the interface of module Bar, are generated automatically by tools
like ocamldep for particular languages.

> It does know (a) the set of LP sources, because you give it the
> first one on the command line and it follows includes.

If a source is missing, how does it know which program to run in order
to create it?

>> Assume that I forget that compilation of a particular file also reads
>> another included file, i.e. forget one dependency link. Then after
>> changing the included file, the target will not be rebuilt (I don't
>> believe that it will, because then all other targets are in the same
>> situation and everything would be rebuilt, which is impractical).
>> So *all* dependencies must be specified. Same as in make.
>
> You are missing the idea -- all the things are not only rebuilt
> every time (in principle) they're rebuilt AT LEAST TWICE.

So it's out for me. My project already takes 7 minutes to build
(90% of the time is gcc, which is slow on generated files having
hundreds of kilobytes). I don't want to turn it into 14 minutes
without a good reason.

And if I make small changes in one file in order to find some bug,
it's essential to recompile only a few relevant files. How does it
know which other files need to be rebuilt if it does not know *all*
dependencies? Rebuilding everything is out of the question. It should
take 7 seconds, not 7 minutes. And it does with make.

I can't say I like make, but any tool which requires to compile some
files twice, or insists on recompiling everything after a local change,
is not a viable alternative.

> As mentioned I personally don't bother with that in Felix package,
> I just use a hand coded linear order (one pass always converges) and
> check each object file against its *.ml file --

The project I have in mind, a compiler of my language Kogut, currently
has 90 modules in its library. I don't even keep the *set* of filenames
in a Makefile, because I would have to change it each time I add or
rename a module. Maintaining a topologically sorted list by hand would
be a nightmare.

It's not written in OCaml, so there are no issues with module order
for linking, but there are issues with slow compilation. So it's
important to compile only what is needed, and to not compile anything
twice.

> You will discover another source of recusive build
> dependencies if you try to bootstrap your language --

It's already self-hosting. The main compiler is written in the
language it compiles.

In order to build it you can either download a smaller package
containing only "real" sources, if you have an earlier version
installed, or download a larger package with pregenerated portable C
files of (a conservative approximation of) the part of the library
used by the compiler and the compiler proper. These C files are used
to bootstrap some working compiler, which is then used instead of the
"previous version".

> and especially if you *also* try to write the build
> tool that manages that in your language too .. :))

This is why I wrote the compiler driver in Perl :-)

It's the program which calls the actual compiler, C compiler,
assembler, assembler mangler (also written in Perl), and linker,
and finds out what options to give to each. It also generates
dependencies for make.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

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