cons-discuss
[Top][All Lists]
Advanced

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

Parallel Cons Issue


From: Nolish, Kevin
Subject: Parallel Cons Issue
Date: Thu, 6 Sep 2001 16:12:36 -0400

I ran into an issue with pcons and multiple line commands that is causing
grief with some of our build scripts.

pcons handles multi-line commands by concatenating them together and issuing
the concatenated command as a single command.  For example

Command $cons <yadda yadda>, qq(
   command1
   command2
     ...
   commandN
)

is transformed into

   command1 && command2 && ...  && commandN

when executed in a multiple job environment ( -j ( > 1) )

In a non multiple environment each command is forked off separately.

The problem is that this transformation isn't quite semantically equivilant.
If any command modifies the environment, subsequent commands will operate in
different environments than expected in multi job environments.

Concrete example

Command $cons, <...>, qq(
     cd %>:d; create tempfile
     cd %>:d; sed -e script tempfile > another_file
     cd %>:d; mv another_file final_file
)

The operator %>:d will be translated into the directory of the build target,
expressed as a relative path.  In uni cons, what ultimately happens is
something like:

system("cd foo/bar;create tempfile")
system("cd foo/bar;sed -e script tempfile > anotherfile")
system("cd foo/bar:mv anotherfile final_file")

In multi cons, what happens is

system("cd foo/bar;create tempfile && cd foo/bar;sed -e ... && cd foo/bar mv
...")

This will fail at the second cd as the command attempts to connect to
foo/bar/foo/bar.

So my first question is "can we nest suffixes?"  If so, I could write
something like 

Command $cons, ..., qq(
   cd %>:a:d; create tempfile
   cd %>:a:d; sed -e ...
   cd %>:a:d; mv
)

This would solve my immediate problem as the :a operator forces an absolute,
as opposed to relative, path.  This doesn't solve the general case.  One can
imagine a command of the form:

Command $cons, ..., qq(
    setenv foo bar:$foo; command_1
    setenv foo bar:$foo; command_2
     ...
);

Again, the value of foo as seen during the execution of command_2 would vary
in the uni and multi build cases.

Thoughts?




Kevin Nolish
724-742-6989
<mailto:address@hidden> 



reply via email to

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