[CMake] Obtaining improved GNU make performance on Makefiles generated by cmake

[Alan W. Irwin]

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 I am committing my changes)
can be obtained by following the directions at
http://sourceforge.net/svn/?group_id=2915.

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
__________________________