A set of custom rules to copy files from the source tree to the build tree
is screwing up for parallel builds on Debian testing with cmake 2.4.7. The
parallel builds are done with "make -j 2" on a core duo system (Intel E6550
2.33 MHz). I am not sure whether the issue is something wrong with our
On 2007-12-12 17:10-0800 Alan W. Irwin wrote:
A set of custom rules to copy files from the source tree to the build tree
is screwing up for parallel builds on Debian testing with cmake 2.4.7. The
parallel builds are done with "make -j 2" on a core duo system (Intel E6550
2.33 MHz).
Before anyb
On 2007-12-12 17:10-0800 Alan W. Irwin wrote:
A set of custom rules to copy files from the source tree to the build tree
is screwing up for parallel builds on Debian testing with cmake 2.4.7.
Here is part of the "make -j 2" output:
make -f examples/tcl/CMakeFiles/tclIndex_examples_tcl.dir/bu
Alan W. Irwin wrote:
My obvious next step is to try and make a simple CMake example that
reliably
reproduces the bug, but this is such an important bug (at least for those
with access to multiprocessors who want to use parallel builds) that I
thought the above result was worth reporting immedia
On 2007-12-13 15:39-0500 Bill Hoffman wrote:
Alan W. Irwin wrote:
My obvious next step is to try and make a simple CMake example that
reliably
reproduces the bug, but this is such an important bug (at least for those
with access to multiprocessors who want to use parallel builds) that I
thoug
Alan W. Irwin wrote:
> It was good to hear that make -j N normally works with CMake.
Yes indeed. I frequently run make -j70 across a 35-host dual-CPU
cluster using distcc, and every time I've updated CMake's files, it's
correctly rebuilt the makefiles before continuing.
http://www.cmake
Alan W. Irwin wrote:
> So just keeping narrowly focussed on that fragment there is only one "ALL"
> custom target and ADD_DEPENDENCIES would not help since it only works on
> targets. Thus, I doubt there is anything locally wrong with dependencies
> there. It is possible some other dependency is
On 2007-12-13 17:07-0500 Brad King wrote:
Alan W. Irwin wrote:
So just keeping narrowly focussed on that fragment there is only one "ALL"
custom target and ADD_DEPENDENCIES would not help since it only works on
targets. Thus, I doubt there is anything locally wrong with dependencies
there. It
Alan W. Irwin wrote:
> So the rule seems to be that parallel builds do not work if there are two
> or more separate custom targets that file depend directly or indirectly
> (via
> some custom command file dependency chain) on the same output files.
>
> Another way of summarizing these results is t
On 2007-12-13 19:15-0500 Brad King wrote:
Alan W. Irwin wrote:
So the rule seems to be that parallel builds do not work if there are two
or more separate custom targets that file depend directly or indirectly
(via
some custom command file dependency chain) on the same output files.
Another way
On 2007-12-13 18:45-0800 Alan W. Irwin wrote:
Brad, I am struggling with understanding the recursive make system that
CMake normally employs so I am having trouble following the complete
Makefile logic that my simple example creates. However,
CMakeFiles/tclIndex_examples_tcl2.dir/build.make gen
Alan W. Irwin wrote:
> I am struggling with understanding the recursive make system that
> CMake normally employs
CMake employs a 2-level make recursion system that is independent of the
directory structure. The first level never builds anything...it just
evaluates target-level dependencies with
You might also want to consider visual studio builds. It will build two
targets at the same time if there is no dependency between them, and
would have the same issue.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo
On 2007-12-14 10:32-0500 Brad King wrote:
Alan W. Irwin wrote:
I am struggling with understanding the recursive make system that
CMake normally employs
CMake employs a 2-level make recursion system that is independent of the
directory structure. The first level never builds anything...it jus
On 2007-12-14 12:49-0500 Bill Hoffman wrote:
You might also want to consider visual studio builds. It will build two
targets at the same time if there is no dependency between them, and would
have the same issue.
Currently, we have had no reports about such problems. However, our windows
de
On 2007-12-14 09:53-0800 Alan W. Irwin wrote:
Obviously, CMake 2.4.x users are stuck with these file dependency issues and
their workarounds, but for obvious reasons and especially for the parallel
build case I hope the complete rework of the CMake dependency system that
has been mentioned previ
Alan W. Irwin wrote:
Well, it turns out I had to add four different target dependencies to the
CMake-based PLplot build system to get rid of the parallel build problems I
was having on my Core Duo box. One of them was pretty subtle so I
missed it
for my first review of the dependencies. Nevert
On 2007-12-15 12:57-0500 Brad King wrote:
Alan W. Irwin wrote:
Well, it turns out I had to add four different target dependencies to the
CMake-based PLplot build system to get rid of the parallel build problems
I
was having on my Core Duo box. One of them was pretty subtle so I missed
it
fo
Alan W. Irwin wrote:
So let me rephrase the question. Are the CMake developers happy with the
present state of the dependencies system or are you considering some major
changes there because of such issues as the difficulties in getting
parallel
builds to work properly for projects like PLplot
On 2007-12-14 09:53-0800 Alan W. Irwin wrote:
On 2007-12-14 10:32-0500 Brad King wrote:
CMake employs a 2-level make recursion system that is independent of the
directory structure. The first level never builds anything...it just
evaluates target-level dependencies with phony targets. That
Alan W. Irwin wrote:
On 2007-12-14 09:53-0800 Alan W. Irwin wrote:
On 2007-12-14 10:32-0500 Brad King wrote:
CMake employs a 2-level make recursion system that is independent of the
directory structure. The first level never builds anything...it just
evaluates target-level dependencies with
Alan W. Irwin wrote:
On 2007-12-14 09:53-0800 Alan W. Irwin wrote:
On 2007-12-14 10:32-0500 Brad King wrote:
CMake employs a 2-level make recursion system that is independent of the
directory structure. The first level never builds anything...it just
evaluates target-level dependencies with
On 2008-02-06 21:05-0500 Bill Hoffman wrote:
Could we have a cmake command-line option to evaluate/diagnose the
complete
list of file and target dependencies as understood by cmake? You could
start
with a print out of complete target dependency chains and file dependency
chains as cmake unders
Alan W. Irwin wrote:
My first interpretation was "that" referred to graphviz, but in fact the
file was produced at cmake time, and it was a simple matter to process
it by
hand using the "dot" command-line tool (even though I had never heard of
that tool or graphviz before). "gv" has errors fo
On 2008-02-06 21:04-0500 Brad King wrote:
Alan W. Irwin wrote:
On 2007-12-14 09:53-0800 Alan W. Irwin wrote:
On 2007-12-14 10:32-0500 Brad King wrote:
CMake employs a 2-level make recursion system that is independent of
the
directory structure. The first level never builds anything...it
On 2008-02-06 22:37-0500 Bill Hoffman wrote:
Alan W. Irwin wrote:
No file level depends are done mostly a build time. This is a performance
issue. Some generators like VS IDE do file level depends by themselves.
With the makefiles cmake computes the depends, but at build time not cmake
ti
26 matches
Mail list logo
