cons-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pcons - problems solved


From: Timothee Besset
Subject: Re: pcons - problems solved
Date: Thu, 6 Jun 2002 09:21:41 +0200

I'm not sure this tackles what the problem actually is. The problem is
specific to the 'Default' command. It's about the way cons decides what
needs to be built (i.e., what are the final targets).

The testcase on http://zerowing.idsoftware.com/pcons/ for that problem
does this:

# pcons test
  
Default '.';
  
$env = new cons(
  CC => './gcc-slow.sh'
  );
  
Program $env 'test', 'main.c', 'func.c';

Now, that Default '.'; statement causes cons to determine what needs to be
built. Instead of deciding that the target is 'test', it puts the two
intermediate object files (main.o and func.o) as targets too.

If you do a Default 'test'; instead, then the parallelizing will work.

If we want Default <directory>; to work for pcons, we'd need to change it
to do something like pushing only the leafs of the tree as targets, and
not the intermediate objects.

I'm not sure it's important to fix this though. Or put a warning in pcons
code when Default <directory>; is used. Just something a pcons user should
know.

TTimo

On Wed, 5 Jun 2002 17:48:18 +0200 (MEST)
Johan Holmberg <address@hidden> wrote:

> 
> On Wed, 5 Jun 2002, Gary Oberbrunner wrote:
> >
> > If anyone knows how to figure out which of a list of targets are
> > dependent on other targets (directly or indirectly), we can probably
> > make this Default '.' stuff work.  If you have any ideas, let Timo or me
> > know.
> >
> 
> I'm not sure what kind of answer you expect. I don't know anything
> about 'pcons', but a general Cons-answer I think would be:
> 
> The only code that knows what the dependency tree looks like is the
> "build algorithm" itself in Cons. And this code is distributed both
> in the "main" program of Cons, and in methods in the "file" class
> (at least).
> 
> And since dependencies can be discovered at "tree-walking-time" (eg.
> those detected by C-scanners) I think *no* code that just looks at a
> "static" dependency tree can get everything right in all details.
> 
> Maybe I answered the wrong question ??  ;-)
> 
> 
> /johan holmberg
> 
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]