CMake Proposal

[Bill Hoffman]

Stefan (metze) Metzmacher wrote:

>> -  command line interface to CMake and -Dvar=value is verbose
> 
> I think the most important missing piece is './configure --help'.
> 
> cmake -LH shows something is much less verbose and also
> needs to run all the configure tests before displaying anything.
> 
This is a common request, although a bit tricky to do because CMake is a 
language and to find all the options would require parsing the whole 
thing and evaluating all variables with all possible values.

if(a)
   option(b...)
endif()

However, we have some ideas of how to create an interface to the command 
line that would allow for -- type options.  It has never been such a big 
problem that we have implemented it.   IMO, a project should not require 
lots of options.  The default build should pretty much do the right 
thing.  There might be a few high level options, the rest of them should 
be advanced, and the cmake gui's cmake-gui and ccmake are good at 
presenting that information.

> 
> One reason for starting our custom build system to prevent/notice
> user errors (e.g. typos and impossible dependecies).
> Dependencies should be specified only in one place
> and the build system should give an error on typos.
> (I know with the current s4 build system this isn't true anymore
>  for all cases)
> 


> Please take a look at
> http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-gladiac-cmake
> for the whole patch.
> 
> Is there a way to warn about uninitialized variables?
> 
Currently, there is not.  It is on a todo list, but currently it is not 
implemented.

> It was also bad that libtevent.so was linked fine, while
> it had unresolved symbols (it wasn't linked to the libtalloc.so,
> because of the typos).
> 
We use the system defaults, if the system does not require shared 
objects to resolve symbols we don't force that.
> Maybe helper functions could make it easier to specifiy dependencies
> just once and have only unique dependencies calculated?
> 
> By unique dependecies I mean:
> - Binary FOO depends on subsystems X,Y,Z
> - X and Y depend on A.
> - FOO should link in A,X,Y,Z (and each only once!)
> 
> The reason for only once is that we pre-link mutliple object files
> into a single object file (MERGED_OBJECT). This is needed on some
> platforms as the cmdline arguments are limited to 1024.
> Using static libraries (.a files) is bad as that would allow
> the linker to optimize out symbols which aren't used by the binary,
> but need to be there for loaded .so modules at runtime.
> 
We pretty much try to preserve the command line that the cmake files 
give us.  This is because of order depends in static linking.  We have 
added the concept of an "imported" target into CMake recently.  This is 
an already built binary, that acts like a target that CMake has built. 
With the use of these targets it should be possible to avoid duplicates 
as CMake will have more information about the types of things it is 
linking.  CMake uses link script files to get around small command 
lines, so it might not be an issue.  I would have to test it on the 
platform you are talking about.
> Also the tevent build should not install the talloc library,
> but I assume that is easy fixable.
> 
Yes, that should be easy to fix.


-Bill