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

[Bill Hoffman]

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

I guess we failed with the message....

"The easiest way to avoid this warning is to set policy CMP0003 to NEW 
and try to build the project. "

So, all you need to do is add a cmake_policy(SET CMP0003 NEW) into the 
top of your project and you should be good.  We are not disallowing 
non-full paths.  However, we are no longer adding -L for ever library we 
use as we were before.  If you are linking non full path stuff we found 
that sometimes it was depending on the -L stuff that CMake was adding. 
There is no way for us to tell.  So, to avoid breaking projects if we 
see you have non-full path link stuff, we add back all the -L stuff for 
the full path libraries you have and issue the warning.  The fix is to 
set the policy to new like this:

IF(COMMAND CMAKE_POLICY)
   CMAKE_POLICY(SET CMP0003 NEW)
ENDIF(COMMAND CMAKE_POLICY)

If your project still links with that change, then you are good.  If it 
can not find a library, then you either need to full path that library 
or add a link_directories call to give the path for the library that can 
not be found.

That said, I tried to build plplot and I got errors with wxWidgets that 
looked like there were missing -I stuff.  So, the command line had stuff 
  like -I-D_WXSOMETHING, so the -D was lost and it caused an error.  I 
have not yet tracked down where the empty -I stuff is coming from in plplot.

-Bill