bksys / scons (Re: win32 port)

[Brad King]

Hello folks,

I am another one of the CMake developers and am happy to answer 
questions.  To follow-up on earlier discussion:

David Faure wrote:
 >>On 1/9/06, Alexander Neundorf <neundorf at kde.org> wrote:
 >>>-they have a fully working configure-like framework, dead-easy to use
 > Is it modular, i.e. does it collect the tests from various subdirs of the
 >  source tree?

Try-compile and try-run results are stored in a single "cache" with a 
specific name.  If multiple subdirectories have the same name for the 
result of a test they all get the answer from the first one that ran the 
test.  The test only runs once.

 >>>-cmake can generate Makefiles and *projects* for KDevelop3, MSVC 6,7,
 >>>XCode
 >
 > Generating Makefiles is probably the ugly thing about it.
 > You don't mention performance; how fast does "make" go on an already 
built
 >  tree, compared to unsermake or bksys?

As of CMake 2.2 the Makefile generator produces a makefile system that 
does not recurse through the directory structure.  There is a fixed 
small number of recursive make calls per major target.  Recursive make 
cannot be completely eliminated due to dependency generation on 
generated sources.  However there is very little overlap in the 
dependencies checked by each make process so for a fully built tree it 
is almost as fast as a single giant makefile.  It is difficult to 
produce numbers for this though because we don't have a single giant 
makefile for any big projects since that design does not work for 
generated sources with implicit dependencies.

 > INSTALL_FILES( /share/apps/kconf_update FILES kcalcrc.upd )
 > shouldn't hardcode /share/apps, but should use some variable for it
 >  (kde_datadir).

Typically projects might do

INSTALL_FILES(${KDE_APPS_DIR} FILES kcalcrc.upd)

 >>>-not sure: relinking during installation
 >
 > That would be awfully slow. Can you look into that? Does it relink during
 >  installation, or relink when launching a local binary (like libtool), or
 >  does it use LD_LIBRARY_PATH (which breaks with rpath, as Thiago said).

There is currently no relinking to deal with rpath.  There are two 
approaches other CMake projects use to deal with running both from the 
build tree and the install tree:

1.) Developers that want to just run immediately from the build tree 
build with CMAKE_SKIP_RPATH set to OFF.  It is reasonably simple to 
setup the CMake code so that no INSTALL rules are generated in this case 
and the developer cannot accidentally install binaries with rpaths to 
the build tree.  Project releases can be setup with CMAKE_SKIP_RPATH set 
to ON and the INSTALL rules created.  Then the installation will have no 
rpath but users can still run from the build tree using LD_LIBRARY_PATH.

2.) Always build with CMAKE_SKIP_RPATH set to ON and then use a "shared 
forwarding" executable:

http://www.paraview.org/cgi-bin/viewcvs.cgi/VTK/Utilities/kwsys/SharedForward.h.in?root=ParaView&view=markup
http://www.paraview.org/cgi-bin/viewcvs.cgi/Servers/Executables/pv-forward.c.in?root=ParaView&view=markup

This executable is a small C program that doesn't link to anything but 
standard system libraries.  It detects whether it is running from the 
build tree or an install tree.  Then it sets up the LD_LIBRARY_PATH or 
equivalent variable on a given platform and exec's the real executable. 
  This is similar to shell scripts used by some commercial tools but 
works on Windows too.  In the build tree case it knows where to find the 
libraries.  In the install tree case it computes the location relative 
to the executable or full-paths can be hard-coded.

Approach #2 requires no rpath or relinking at all and allows programs to 
be run both from the build tree and an arbitrarily-located install tree.

If you want a more customizable rpath with the option of install-time 
rpath changing I have some ideas on how to implement them in CMake.  I 
can give you more details on any of these approaches.

-Brad