Bill Hoffman wrote:
Filipe Sousa wrote:
Is that 6 minutes?? The test is to run make in a tree that has
everything already built. We not trying to measure the speed of the
compiler but rather the speed of make checking the depend information.
Oops!
There you go
*cmake version
Bill Hoffman wrote:
Bill Hoffman wrote:
Sure, it will take some time to do this, as a build of paraview can
take some time, and I will have to do it twice. However, with the
single target in ParaView case, I know when Brad made the change he
saw significant speed ups, but I do not have
Clinton Stimpson wrote:
I was getting better numbers than that with parallel builds (is that
expected?).
A plain make was a touch faster, and make pqCore was almost 2x as fast.
Yes, parallel builds should be faster, as the checks for some targets
can be done in parallel. I was just trying
Bill Hoffman wrote:
Clinton Stimpson wrote:
I was getting better numbers than that with parallel builds (is that
expected?).
A plain make was a touch faster, and make pqCore was almost 2x as fast.
Yes, parallel builds should be faster, as the checks for some targets
can be done in
On Tuesday 25 March 2008, Alan W. Irwin wrote:
On 2008-03-25 14:28-0400 Bill Hoffman wrote:
...
Thanks, Bill, for running these paraview latency tests. My view is they
should decide the matter unless KDE or some other project with similar or
larger latency to paraview disagrees with the
Alan W. Irwin wrote:
On 2008-03-25 14:28-0400 Bill Hoffman wrote:
--- build all of paraview with nothing needing a build:
2.6
make 15.21s user 5.55s system 74% cpu 28.049 total
make 15.44s user 5.35s system 98% cpu 21.073 total
make -j5
real6m13.039s
user20m42.308s
sys
Filipe Sousa wrote:
Alan W. Irwin wrote:
On 2008-03-25 14:28-0400 Bill Hoffman wrote:
--- build all of paraview with nothing needing a build:
2.6
make 15.21s user 5.55s system 74% cpu 28.049 total
make 15.44s user 5.35s system 98% cpu 21.073 total
make -j5
real6m13.039s
user
One more warning about adding your own -I flags... I think this will
break the dependency scanner of CMake, and the depends will be wrong if
you do not use include_directories.
-Bill
___
CMake mailing list
CMake@cmake.org
On 2008-03-24 10:27-0400 Bill Hoffman wrote:
One more warning about adding your own -I flags... I think this will break
the dependency scanner of CMake, and the depends will be wrong if you do not
use include_directories.
Our use case is we have a directory where our many different device
On 2008-03-24 10:33-0400 Bill Hoffman wrote:
OK, I talked with Brad, and found out the difference from 2.4.8 and CVS.
When make runs in a CMake project, the first thing it does is run cmake to
check the depend information. It looks for missing header files, and other
checks to see if CMake
OK, so for a small project like PLplot, where it does a make in 1 to 2
seconds if nothing needs to be done, this stuff really does does not
matter that much. Adding the phony targets may have actually made it
take longer as make would have to parse that much more stuff. As for
the new way
Hi Bill:
I just now tested (with the build on one of the PLplot C examples)
the assertion that specific targets will have less latency
with the new approach. Here are the results.
[EMAIL PROTECTED] make x10c
[ 0%] Built target plhershey-unicode-gen
[ 0%] Built target
Alan W. Irwin wrote:
I have previously asked Alex to do the KDE case. Bill, would you be
willing
to measure latency for ParaView for cmake 2.4.8 and the present cvs version
of CMake?
Sure, it will take some time to do this, as a build of paraview can take
some time, and I will have to
On 2008-03-18 10:06-0400 Bill Hoffman wrote:
I played around with make -d and -p and found that the .SUFFIXES rule that
was supposed to be removing the implicit rules for gmake was not working for
everything. SCCS and RCS were being checked for a bunch of stuff. Anyway,
try this and see
Alan W. Irwin wrote:
On 2008-03-18 10:06-0400 Bill Hoffman wrote:
I played around with make -d and -p and found that the .SUFFIXES rule
that was supposed to be removing the implicit rules for gmake was not
working for everything. SCCS and RCS were being checked for a bunch
of stuff.
Alan W. Irwin wrote:
On 2008-03-20 12:50-0400 Bill Hoffman wrote:
Alan W. Irwin wrote:
On 2008-03-18 10:06-0400 Bill Hoffman wrote:
I played around with make -d and -p and found that the .SUFFIXES
rule that was supposed to be removing the implicit rules for gmake
was not working for
The GNU make documentation states the following:
Since it knows that phony targets do not name actual files that
could be remade from other files, make skips the implicit rule search
for phony targets This is why declaring a
target phony is good for [make] performance
Also,
Alan W. Irwin wrote:
The GNU make documentation states the following:
Since it knows that phony targets do not name actual files that
could be remade from other files, make skips the implicit rule search
for phony targets This is why declaring a
target phony is good for [make]
18 matches
Mail list logo
