Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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 2.7-20080325* make real0m3.519s user0m6.100s sys 0m1.314s make -j5 real0m3.514s user0m6.083s sys 0m1.299s *cmake 2.4.8* make real0m2.777s user0m5.725s sys 0m1.058s make -j5 real0m2.741s user0m5.767s sys 0m1.038s signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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 the numbers. OK, so the results are in for ParaView which has a total of 144 targets. --- 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 2.4 make 14.40s user 5.09s system 59% cpu 32.793 total make 14.73s user 4.74s system 98% cpu 19.684 total * There is a 5 second delay before seeing the first line of output from a 2.4 build tree on ParaView, no delay in 2.6 2.6 is less than a second slower, but perception is better because there is no delay without output. --- build a target that only depends on only one other target. ( 2.6 is about 3 seconds faster in this case.) 2.6 silverymoon:paraview3-build-cmake26 make vtkCommon [ 0%] Built target vtksys [100%] Built target vtkCommon silverymoon:paraview3-build-cmake26 time make vtkCommon [ 0%] Built target vtksys [100%] Built target vtkCommon make vtkCommon 0.43s user 0.08s system 99% cpu 0.513 total silverymoon:paraview3-build-cmake26 time make vtkCommon [ 0%] Built target vtksys [100%] Built target vtkCommon make vtkCommon 0.44s user 0.08s system 99% cpu 0.522 total silverymoon:paraview3-build-cmake26 time make vtkCommon [ 0%] Built target vtksys [100%] Built target vtkCommon make vtkCommon 0.41s user 0.10s system 99% cpu 0.515 total 2.4 silverymoon:paraview3-build time make vtkCommon [ 0%] Built target vtksys [100%] Built target vtkCommon make vtkCommon 3.32s user 5.70s system 99% cpu 9.025 total silverymoon:paraview3-build time make vtkCommon [ 0%] Built target vtksys [100%] Built target vtkCommon make vtkCommon 3.24s user 5.81s system 99% cpu 9.059 total --- Build a target that depends on 60 other targets 2.6 make vtkPVServerManager 9.70s user 3.04s system 99% cpu 12.754 total make vtkPVServerManager 9.64s user 2.91s system 99% cpu 12.569 total 2.4 make vtkPVServerManager 11.40s user 6.38s system 99% cpu 17.955 total make vtkPVServerManager 11.19s user 6.58s system 99% cpu 17.774 total In summary, I would say 2.6 or CVS is better. We only loose less than a second out of 15 on the total, and we gain 2 or 3 on single targets. 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. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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 show the worst case and get the amount of time make spends doing nothing but checking times. Of course if it can do nothing in parallel it will be that much faster at doing nothing... :) -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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 parallel. I was just trying show the worst case and get the amount of time make spends doing nothing but checking times. Of course if it can do nothing in parallel it will be that much faster at doing nothing... :) -Bill Right, in general, it is faster. To clarify, I meant a parallel build (-j4) of pqCore was twice as fast with CMake 2.6 than in 2.4. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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 paraview results you obtained. I didn't measure yet for KDE but it should be similar to paraview. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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 2m43.996s user+system = 20.76s and 20.79s for the two runs. 2.4 make 14.40s user 5.09s system 59% cpu 32.793 total make 14.73s user 4.74s system 98% cpu 19.684 total user+system = 19.49s and 19.47s for the two runs make -j5 real6m14.700s user20m39.125s sys 2m46.430s System: gentoo-32, linux-2.6.24, gcc-4.2.3, core2quad q6600 4gb ram, 2x320 sataII raid0 signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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 user20m42.308s sys 2m43.996s user+system = 20.76s and 20.79s for the two runs. 2.4 make 14.40s user 5.09s system 59% cpu 32.793 total make 14.73s user 4.74s system 98% cpu 19.684 total user+system = 19.49s and 19.47s for the two runs make -j5 real6m14.700s user20m39.125s sys 2m46.430s 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. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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 http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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 drivers are built with wildly varying compilation flag (both -I and -D) requirements. So it seemed natural to use SET_SOURCE_FILES_PROPERTIES( ... PROPERTIES COMPILE_FLAGS ...) to handle each device driver separately rather than using ADD_DEFINITIONS and INCLUDE_DIRECTORIES. The method appears to work fine, but I haven't tested the case where some external library header has been changed to see if CMake responds properly. I will probably just stick with the present method until CMake adds the feature of per-target ADD_DEFINITIONS and INCLUDE_DIRECTORIES (assuming they do handle the external dependency case correctly). For PLplot headers scattered all over our build tree for our various libraries we do use INCLUDE_DIRECTORIES to find them so all the internal dependencies should be correct. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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 should re-run or not. In 2.4.8, CMake would do this globally for the whole project. These made a delay as CMake checked all the depends for the whole project. CMake now checks each targets header files separately. This means two things. First, if you are only building one target, then it should be much faster as all the headers for the entire project are not checked. Second, the initial delay for the project is much less, but over all time may increase some as the check is now done for each target and shared headers maybe double checked. That sounds like a good working hypothesis for the substantially increased latency of the cvs version, but you should probably confirm that analysis with some -d runs to make absolutely sure. If that hypothesis is confirmed, and if your judgement is most developers simply type make the majority of the time (which is what I tend to do) without bothering with individual targets, then you may want to reconsider that change because of the substantially increased latency penalty associated with it. That said, I have checked in a change to get PHONY targets into CMake, as it should not break other makes. This should help some, and it should fix the make test problem when you had a directory called test. make test sparked this investigation, but I have long since solved that issue by renaming our test subdirectory as plplot_test since we are a cross-platform product where some of our Unix users do not have access to GNU make. So the emphasis for most of this thread has simply focussed on the important issue of reducing the latency for GNU make users, and I really appreciate your attempts to address that issue. Unfortunately, the results for your newly implemented .PHONY support for GNU make are disappointing for some unknown reason. Just to review, the PLplot make latency for cmake 2.4.8 is [EMAIL PROTECTED] time make /dev/null real0m1.454s user0m0.800s sys 0m0.724s and for cmake version 2.7-20080320 is is real0m2.319s user0m1.356s sys 0m1.068s with timing errors of +/- 0.01 s or so for each measurement. For cmake version 2.7-20080324 (which includes your .PHONY changes as I checked with actual results in the build-tree Makefiles) that latency has been increased by a small amount that appears to be above the timing errors. [EMAIL PROTECTED] time make /dev/null real0m2.375s user0m1.444s sys 0m1.028s I notice cmake_force is still in the generated Makefiles for cmake 2.7-20080324. It's count is reduced compared to the number of .PHONY instances. [EMAIL PROTECTED] find -type f |xargs grep cmake_force |wc -l 824 [EMAIL PROTECTED] find -type f |xargs grep .PHONY |wc -l 5849 Both the above commands were executed from the top of the build tree. You should be able to eliminate cmake_force altogether for GNU make since .PHONY duplicates its function. My guess from the count above is that will make a noticable difference. I think it requires a CMake and make guru to find out what is really going on using a through investigation comparing cmake 2.4.8 with cmake 2.7-20080320 and cmake 2.7-20080324 with the make -d option. I am not that guru (all I know is that make -d outputs an enormous number of results which are hard for me to understand), but if one of the CMake developers wants to investigate further, PLplot should be a reasonably accessible test bed for such investigations. Note with PLplot there are a large number of options to simplify the build. For example, you easily can eliminate all the non-C language interfaces and/or the devices to simplify comparisons. You should probably check other projects as well including a simple hello-world project if timing errors don't completely swamp the results in that case. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by 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 cmake does the depend stuff, I think the new approach is much better for larger projects like KDE/ParaView. Basically for those larger projects make sometarget was almost unusable. We create sometarget/fast to get around the problem, but people lost some depend checks. It is basically a trade off between large and small projects. If it only takes a fraction of a second longer for the small project but saves minutes on the larger projects, then lets save minutes. The phony change is good because it fixes the make test issue. I think the makefiles are tuned well enough for me right now. If someone wants to contribute patches that show improvement that is fine as well. The cmake_force stuff is not used that much anyway. It is only used for foo.i which are targets that are not part of the all build anyway. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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 plhershey-unicode.h_built [ 0%] Built target csirocsa [ 16%] Built target csironn [100%] Built target plplotd [100%] Built target x10c As you can see from this, the number of dependencies is fairly small. Furthermore, the VERBOSE=1 results indicate there are no actual commands being run by the above so this is a measure of true latency. Here are the corresponding latency results: 2.4.8: [EMAIL PROTECTED] time make x10c /dev/null real0m0.217s user0m0.160s sys 0m0.068s 2.7-20080324: [EMAIL PROTECTED] time make x10c /dev/null real0m0.209s user0m0.168s sys 0m0.036s Repeat runs indicate for this special case with a small number of dependencies, the timing errors are typically +/- 0.002 s. The conclusion therefore is the cvs version wins on latency for a specific target by a marginal amount that is just above the timing noise. On 2008-03-24 15:28-0400 Bill Hoffman wrote: 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. As for the new way cmake does the depend stuff, I think the new approach is much better for larger projects like KDE/ParaView. Large projects have the most serious potential latency problems (could be minutes rather than seconds if the number of dependencies is very high) so I agree they should be the ones driving latency improvements rather than PLplot. The only advantage of using PLplot for such tests is the initial build can be done in less than a minute so doing differential comparisons between various CMake versions is easy to do. In any case, it's fundamentally important not to guess about latency because reducing latency is generally a hard problem. Thus, before the next release I hope somebody steps forward with actual latency numbers for specific targets and the all target for large projects like KDE/ParaView. But it currently doesn't look good since the indications from the PLplot tests (which so far is the only hard data that has been reported) is the latency for make all will be substantially worse while the latency for specific targets with a lot fewer dependencies then all are only marginally better for the cvs version compared to 2.4.8. The principal conclusion I want to emphasize is the PLplot latency results are just an indication of what to expect in general, and what we need is hard latency numbers for big projects like KDE, ParaView, etc., (where latency issues should be more severe than in the PLplot case). That's the only way we can move forward with any further attempts to substantially improve latency. 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? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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 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 the numbers. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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 if it improves the issue you were seeing: $ cvs commit -m ENH: try to improve make speed by getting rid of some implicit rules that were still around. cmLocalUnixMakefileGenerator3.cxx /cvsroot/CMake/CMake/Source/cmLocalUnixMakefileGenerator3.cxx,v -- cmLocalUnixMakefileGenerator3.cxx new revision: 1.241; previous revision: 1.240 Hi Bill: It's going to take a while because I am running into problems configuring and building PLplot with the cvs version of CMake. Some if not all of this is our fault. For example, the cvs version of CMake has warned about non-unique target names which is an issue I definitely want to address. Also, the PLplot build fails, but I want to get rid of the cmake warnings before investigating that build issue any further. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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. Anyway, try this and see if it improves the issue you were seeing: $ cvs commit -m ENH: try to improve make speed by getting rid of some implicit rules that were still around. cmLocalUnixMakefileGenerator3.cxx /cvsroot/CMake/CMake/Source/cmLocalUnixMakefileGenerator3.cxx,v -- cmLocalUnixMakefileGenerator3.cxx new revision: 1.241; previous revision: 1.240 Hi Bill: It's going to take a while because I am running into problems configuring and building PLplot with the cvs version of CMake. Some if not all of this is our fault. For example, the cvs version of CMake has warned about non-unique target names which is an issue I definitely want to address. Also, the PLplot build fails, but I want to get rid of the cmake warnings before investigating that build issue any further. Before you fix PLplot, I would be interested in knowing why it does not build with CVS CMake warnings and all. What OS/compiler are you having trouble with? Where/how can I download PLplot and try it myself. Thanks. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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 everything. SCCS and RCS were being checked for a bunch of stuff. Anyway, try this and see if it improves the issue you were seeing: $ cvs commit -m ENH: try to improve make speed by getting rid of some implicit rules that were still around. cmLocalUnixMakefileGenerator3.cxx /cvsroot/CMake/CMake/Source/cmLocalUnixMakefileGenerator3.cxx,v -- cmLocalUnixMakefileGenerator3.cxx new revision: 1.241; previous revision: 1.240 Hi Bill: It's going to take a while because I am running into problems configuring and building PLplot with the cvs version of CMake. Some if not all of this is our fault. For example, the cvs version of CMake has warned about non-unique target names which is an issue I definitely want to address. Also, the PLplot build fails, but I want to get rid of the cmake warnings before investigating that build issue any further. Before you fix PLplot, I would be interested in knowing why it does not build with CVS CMake warnings and all. What OS/compiler are you having trouble with? Where/how can I download PLplot and try it myself. I have already fixed the non-unique target names since we definitely want unique ones. Also, instead of specifying the math library as m now (on non-Windows systems), I now search for it properly to get its full path name. The two remaining areas of concern are fortran 95 (where I suspect one of our horrible workarounds to make fortran 95 work on 2.4.8 is interfering with the proper fortran 95 support in Cmake cvs), and wxwidgets. Here is the full warning message about the wxwidgets problem: CMake Warning (dev) at bindings/wxwidgets/CMakeLists.txt:49 (add_library): Policy CMP0003 is not set: Libraries linked via full path no longer produce linker search paths. Run cmake --help-policy CMP0003 for policy details. Use the cmake_policy command to set the policy and suppress this warning. The easiest way to avoid this warning is to set policy CMP0003 to NEW and try to build the project. If any libraries in the second list below cannot be found then either convert them to be specified with a full path or use the link_directories command to add the missing linker search path. Target plplotwxwidgetsd links to some items by full path not located in any linker search directory added by a link_directories command: /home/software/plplot_cvs/HEAD/build_cvs/bindings/c++/libplplotcxxd.so.9.3.0 /home/software/plplot_cvs/HEAD/build_cvs/src/libplplotd.so.9.5.0 /home/software/plplot_cvs/HEAD/build_cvs/lib/csa/libcsirocsa.so.0.0.1 /home/software/plplot_cvs/HEAD/build_cvs/lib/nn/libcsironn.so.0.0.1 This is okay but it also links to some items with no path known: -pthread, -lwx_gtk2u_xrc-2.6, -lwx_gtk2u_qa-2.6, -lwx_gtk2u_html-2.6 -lwx_gtk2u_adv-2.6, -lwx_gtk2u_core-2.6, -lwx_baseu_xml-2.6 -lwx_baseu_net-2.6, -lwx_baseu-2.6 This may be okay too because the linker will search for the libraries in the second list. However, finding them may depend on linker search paths earlier CMake versions added as an implementation detail for linking to the libraries in the first list. For compatibility CMake is including the extra linker search paths, but policy CMP0003 should be set by the project. This warning is for project developers. Use -Wno-dev to suppress it. Later I get build problems with anything wxwidgets related so clearly the above warning about using -l options rather than full pathname of the wxwidgtets libraries should be taken seriously. Apparently, there is something I can set with cmake_policy to get the old linking behaviour that accepts the above linker flags, but cmake_policy is not documented for 2.4.8. If this means it does not exist there, would you suggest I make its use dependent on whether CMAKE_CACHE_MINOR_VERSION is greater than 4 or not? BTW, CMAKE_BACKWARDS_COMPATIBILITY (the other variable I was thinking of using) is 2.4 for the cvs version. Is that correct or should that be 2.7? I should also emphasize that any detection of CMake version I would use now for the wxwidgets case would just be temporary because I want to switch to absolute library PATHS for that ASAP. (In fact, I thought I had already made such a switch so the warnings about that from CMake cvs are quite useful.) However, I may need such a test for CMake version for the fortran case since we really do need the horrible workaround I mentioned above for our fortran 95 interface to work properly for 2.4.8. You may not want to try PLplot until I have settled some of these issues, but in case you really do want to immediately try what I am working on, the svn trunk version of the code (which is where
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
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] performance Also, Using .PHONY' is more explicit and more efficient. However, other versions of make' do not support .PHONY'; thus FORCE (an arbitrarily named rule with no prerequisites or rules) appears in many makefiles. As part of another investigation I searched a Linux build tree created by cmake (2.4.8) and was surprised to find no reference to .PHONY. Instead, the makefile generator on Linux is using the same method as FORCE idea above, i.e., a rule called cmake_force with no prerequisites or commands to serve as a prerequisite to rules that must be run every time. CMake is missing a bet on Linux systems to reduce Makefile overhead since it is using this cmake_force approach rather than the preferred more efficient.PHONY approach for rules that must be run every time. Since the Makefiles generated by cmake have an extremely large number of such rules, Makefile latency may be significantly reduced by this method on Linux (GNU make) systems. If the cmake developers here like this idea (or at least don't strongly dislike it), I will go ahead and make a feature request so it doesn't get lost. CMake is written to generic make, and I don't think we would want to add something that only worked with gmake. The trouble is the make you are using can change after CMake is run, so we can not even test for the version of make being used. I guess if it was a big enough performance gain, we could add some sort of option to allow for this. However, I would want to make sure that there would be a good payback. So far the cmake makefiles outperform the autotools ones quite well, and performance has not been an issue. Do you think you are having a performance problem? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
