[CMake] Targets organisation of complex project

[Mateusz Loskot]

Samuel E. Henley wrote:
> Some time ago I built a cmake script for the the library in your 
> example gdal/ogr

Samuel,

That's interesting news. You should have announce it to gdal-dev :-)

> - primarily to generate builds for gcc under Windows and Linux

Our idea is to exploit the power of CMake in terms of write once use
everywhere. Personally, I really want to make life of developers and
users of GDAL based on Windows just easier by providing them with
native build configuration.

> My first approach was to build a library for each of the map format 
> types and the four core libraries cpl, gcore, etc.

Our approach is similar except we thought about building all formats
into single sub-library.

> The libraries (hundreds) would not link and the library order would 
> result in new set of undefined symbols on each attempt.

Yes, the number of potential libraries is huge.

> Gdal/Ogr is built with a makefile, and the objects generated are 
> saved and linked at the end of the processes.

Yes.

> What I did get to work
>  was to include the sources, using cmake include, in each of the four
>  core libraries, setting source file properties for each group of 
> source file cflags. qhite sqhite s
> (http://wush.net/trac/sehenley/browser/simulator/trunk/src/builds/gdalogr)

Sounds as a good but I may have been missing something.
I looked at the scripts and it seems it's based on the same approach as
we are trying to follow. Some of components are built as static libs
linked into single shared lib:

http://wush.net/trac/sehenley/browser/simulator/trunk/src/builds/gdalogr/CMakeLists.txt#L800

>  Previously my system just identified groups of sources for each of 
> four core libraries – that system used an unreasonable amounts of 
> time to maintain. By having the format sources in individual groups (
>  *.cmake) cmake will tell you what source file it can't find – as 
> large libraries the gcc linker will only tell you at the end of the 
> process what symbol it can't find and even worst build a library with
>  undefined symbols to be discoved at run time. You will still have to
>  run down any new source files but the link symbol will give a hint 
> as to where they were added.

I understand.

By the way, how does CMake handle passing such large number of source
files, well or could be better or...

http://wush.net/trac/sehenley/browser/simulator/trunk/src/builds/gdalogr/CMakeLists.txt#L668

I'm wondering if resulting Makefile (for GCC toolset) would allow to
handle multi-process/jobs building.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org