caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Romain Bardou <bardou@lri.fr>
To: "Daniel Bünzli" <daniel.buenzli@erratique.ch>
Cc: OCaml List <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] ocamlbuild & deps
Date: Sat, 21 Feb 2009 19:53:34 +0100	[thread overview]
Message-ID: <49A04DAE.6010109@lri.fr> (raw)
In-Reply-To: <E7CB7566-4DA9-40D1-A205-C9E4E478F6D1@erratique.ch>

Daniel Bünzli wrote:
> 
> Le 20 févr. 09 à 16:39, Romain Bardou a écrit :
> 
>> I think there is a difference. It is indeed an optimization issue but 
>> not at the level of Ocamlbuild itself : it is as the level of your 
>> compilation process. If A *dynamically* depends on B, and your whole 
>> project (say, 10 hours of compilation) depends on A, but you have no 
>> way to build B, then Ocamlbuild will start to compile your project 
>> until it finds out that A cannot be built (maybe several hours later). 
>> If B had been put as a ~dep, then Ocamlbuild would not even had 
>> started building the project in the first place, saving you a lot of 
>> time.
> 
> Heu no. If B cannot be built then the compilation of A stops and the 
> compilation of your project stops.
> 
> It is however true that if A has a dependency on a heavy C in parallel 
> to B you'll have to wait for the end of C. But even in this case, it's 
> just a matter of calling 'build' with B and C in a sensible order (and 
> not in parallel).

Ok I think I did not explain correctly. Let's say that :
- A dynamically depends on B
- A depends on C
- B cannot be built
Now if I try to build A, C will be built, then the rule to build A will 
be applied and the dependency on B will be discovered. But B cannot be 
built so the compilation fails.

Now if the compilation of C takes 10 hours, you will have to wait 10 
hours no matter what. "Damn, I waited 10 hours just to discover that it 
cannot compile!" If the dependency on B was not dynamic, C would not 
have been built at all.

So, there is indeed a difference between dynamic and static 
dependencies, with or without parallelism. In fact, dynamic dependencies 
also tend to break parallelism as dynamic dependencies cannot be built 
at the same time as static dependencies. In my example, C and B cannot 
be built in parallel. This is another difference.

You cannot, in general, run the rule to discover dynamic dependencies 
before building static dependencies. Indeed, what if the rule needs to 
read one of the static dependencies to discover other dependencies?

-- 
Romain Bardou


  reply	other threads:[~2009-02-21 18:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-20 14:01 Daniel Bünzli
2009-02-20 15:39 ` [Caml-list] " Romain Bardou
2009-02-20 16:31   ` Daniel Bünzli
2009-02-21 18:53     ` Romain Bardou [this message]
2009-02-21 20:19       ` Daniel Bünzli
2009-02-21 20:23         ` Daniel Bünzli
2009-02-26 13:04         ` Daniel Bünzli
2009-03-02 13:43           ` Daniel Bünzli

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=49A04DAE.6010109@lri.fr \
    --to=bardou@lri.fr \
    --cc=caml-list@yquem.inria.fr \
    --cc=daniel.buenzli@erratique.ch \
    /path/to/YOUR_REPLY

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

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