Re: [CMake] Targets organisation of complex project
Mateusz Loskot wrote: What would be best way to configure such complex source tree that outputs single library? I'm trying to make my decision, so I would like to summary our brainstorm. AFAIU, linking the static libraries to single shared library is still not recommended. The recommended option is to pass all source files at once to ADD_LIBRARY call. Next, there is a couple of ways how to achieve that like appending names to variables (brute force), using PARENT_SCOPE thing, get_directory_property etc. Would that be correct? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
On Tuesday 13 October 2009, Mateusz Loskot wrote: Mateusz Loskot wrote: What would be best way to configure such complex source tree that outputs single library? I'm trying to make my decision, so I would like to summary our brainstorm. AFAIU, linking the static libraries to single shared library is still not recommended. The recommended option is to pass all source files at once to ADD_LIBRARY call. Next, there is a couple of ways how to achieve that like appending names to variables (brute force), What is brute force about that ? using PARENT_SCOPE thing, If you do that, remember to use the full paths, otherwise the relative paths will be wrong. get_directory_property etc. Would that be correct? I think so. Alex ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
Alexander Neundorf wrote: On Tuesday 13 October 2009, Mateusz Loskot wrote: Mateusz Loskot wrote: What would be best way to configure such complex source tree that outputs single library? I'm trying to make my decision, so I would like to summary our brainstorm. AFAIU, linking the static libraries to single shared library is still not recommended. The recommended option is to pass all source files at once to ADD_LIBRARY call. Next, there is a couple of ways how to achieve that like appending names to variables (brute force), What is brute force about that ? Actually, nothing. I just wanted to describe the process of collecting sources with plain SET() command while walking down-up the tree of subdirectories, one by one, appending, etc. using PARENT_SCOPE thing, If you do that, remember to use the full paths, otherwise the relative paths will be wrong. Right. get_directory_property etc. Would that be correct? I think so. Great. Things are getting clear :-) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
Zitat von Mateusz Loskot mate...@loskot.net: Trying to figure out how to organise targets I got an idea to configure these sub-libraries as static library targets (e.g. libgdal_cpl, libgdal_alg, libgdal_gcore, etc.) which eventually link to single shared library (libgdal.so). Learning CMake best practices, I stepped across an interesting thread: build a shared library from static libraries http://www.cmake.org/pipermail/cmake/2008-March/020315.html It actually smashed my original idea :-) Why? I think you misunderstood what is written there. It just tells you that the interdependencies of those static libs must be tree-like. If you cannot ensure this within your project, then you must use the all-at-once approach. HS ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
On Mon, Oct 12, 2009 at 4:54 PM, Hendrik Sattler p...@hendrik-sattler.de wrote: Zitat von Mateusz Loskot mate...@loskot.net: http://www.cmake.org/pipermail/cmake/2008-March/020315.html It actually smashed my original idea :-) Why? I think you misunderstood what is written there. It just tells you that the interdependencies of those static libs must be tree-like. If you cannot ensure this within your project, then you must use the all-at-once approach. Quoting from the linked mail, Combining static libs into a shared lib is not really portable, you have to take care that you use the correct linker flags for the libs so that it will work. This is the reason I wouldn't consider the link all the static libs into a shared lib approach. For instance, on x86_64/gcc you need to compile any files which will eventually become shared objects with the -fPIC flag, but this doesn't happen automatically when creating static libs. AFAIK the flag isn't necessary on x86, and it may be something different again on other platforms, hence the not really portable comment I suppose. ~Chris ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
Some time ago I built a cmake script for the the library in your example gdal/ogr – primarily to generate builds for gcc under Windows and Linux – My first approach was to build a library for each of the map format types and the four core libraries cpl, gcore, etc. The libraries (hundreds) would not link and the library order would result in new set of undefined symbols on each attempt. Gdal/Ogr is built with a makefile, and the objects generated are saved and linked at the end of the processes. 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. (http://wush.net/trac/sehenley/browser/simulator/trunk/src/builds/gdalogr) 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. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
Tyler Roscoe wrote: On Sun, Oct 11, 2009 at 08:41:27PM +0100, Mateusz Loskot wrote: The sources are organised in large number of subdirectories and sort of logical sub-libraries, but the binary output of compilation is a single library. [snip] It looks like the best portable approach is to walk through the whole tree of project, collect all .c and .cpp files (assigning list of files to global variables) and, back in the main CMakeLists.txt, stream all source files to single ADD_LIBRARY call. This is what I would do. IME, CMake works best when you do the simplest thing that can possibly work. I agree, but there may be some tricks lurking. For example, does CMake promise to handle well situation when two source files with the same name but in different locations are used in common ADD_LIBRARY call, like here: ADD_LIBRARY(mylib abc/algorithm.cpp xyz/algorithm.cpp) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
Philip Lowman wrote:
On Sun, Oct 11, 2009 at 9:01 PM, Tyler Roscoe ty...@cryptio.net wrote:
On Sun, Oct 11, 2009 at 08:41:27PM +0100, Mateusz Loskot wrote:
The sources are organised in large number of subdirectories and
sort of logical sub-libraries, but the binary output of compilation
is a single library.
[snip]
It looks like the best portable approach is to walk through the whole
tree of project, collect all .c and .cpp files (assigning list of files
to global variables) and, back in the main CMakeLists.txt, stream all
source files to single ADD_LIBRARY call.
This is what I would do. IME, CMake works best when you do the simplest
thing that can possibly work.
I would do what makes sense in terms of the end user. If those separate
subdirectories are meant to be separate libraries, then build separate
libraries. If the source code is scattered across multiple subdirectories
but is all supposed to be part of the same library then build it together.
The case here is the latter one. Single library is the only reasonable
output of the build of our project.
You can use PARENT_SCOPE to hand lists of source files up a directory, if
that is of interest.
set(FOO_SRCS ${list_of_sources} PARENT_SCOPE)
Thanks for the hint. I'll learn more about this.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
Hendrik Sattler wrote: Zitat von Mateusz Loskot mate...@loskot.net: Trying to figure out how to organise targets I got an idea to configure these sub-libraries as static library targets (e.g. libgdal_cpl, libgdal_alg, libgdal_gcore, etc.) which eventually link to single shared library (libgdal.so). Learning CMake best practices, I stepped across an interesting thread: build a shared library from static libraries http://www.cmake.org/pipermail/cmake/2008-March/020315.html It actually smashed my original idea :-) Why? I think you misunderstood what is written there. I believe I have understood it well and I got it exactly as Chris Foster explained it. (Thanks Chris!) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
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 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
On Sun, Oct 11, 2009 at 08:41:27PM +0100, Mateusz Loskot wrote: The sources are organised in large number of subdirectories and sort of logical sub-libraries, but the binary output of compilation is a single library. [snip] It looks like the best portable approach is to walk through the whole tree of project, collect all .c and .cpp files (assigning list of files to global variables) and, back in the main CMakeLists.txt, stream all source files to single ADD_LIBRARY call. This is what I would do. IME, CMake works best when you do the simplest thing that can possibly work. tyler ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
On Sun, Oct 11, 2009 at 9:01 PM, Tyler Roscoe ty...@cryptio.net wrote:
On Sun, Oct 11, 2009 at 08:41:27PM +0100, Mateusz Loskot wrote:
The sources are organised in large number of subdirectories and
sort of logical sub-libraries, but the binary output of compilation
is a single library.
[snip]
It looks like the best portable approach is to walk through the whole
tree of project, collect all .c and .cpp files (assigning list of files
to global variables) and, back in the main CMakeLists.txt, stream all
source files to single ADD_LIBRARY call.
This is what I would do. IME, CMake works best when you do the simplest
thing that can possibly work.
I would do what makes sense in terms of the end user. If those separate
subdirectories are meant to be separate libraries, then build separate
libraries. If the source code is scattered across multiple subdirectories
but is all supposed to be part of the same library then build it together.
You can use PARENT_SCOPE to hand lists of source files up a directory, if
that is of interest.
set(FOO_SRCS ${list_of_sources} PARENT_SCOPE)
--
Philip Lowman
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
On Mon, Oct 12, 2009 at 12:15 PM, Philip Lowman phi...@yhbt.com wrote:
I would do what makes sense in terms of the end user. If those separate
subdirectories are meant to be separate libraries, then build separate
libraries. If the source code is scattered across multiple subdirectories
but is all supposed to be part of the same library then build it together.
You can use PARENT_SCOPE to hand lists of source files up a directory, if
that is of interest.
set(FOO_SRCS ${list_of_sources} PARENT_SCOPE)
Yeah, this is a pretty good approach. Unfortunately I had difficulty
with it because I needed to use code generation via
add_custom_command() to create some of the source files. I couldn't
seem to get the dependency resolution for the generated files to work
unless I had the custom command inside the *same* CMakeLists.txt which
built the library.
In the absence of code generation, I'd be inclined to go with PARENT_SCOPE.
~Chris
@ Philip: Apologies for the double mail, I'm unused to mailing lists
which require an explicit reply to the list :-/
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
Yeah, this is a pretty good approach. Unfortunately I had difficulty with it because I needed to use code generation via add_custom_command() to create some of the source files. I couldn't seem to get the dependency resolution for the generated files to work unless I had the custom command inside the *same* CMakeLists.txt which built the library. Could you please give more insight into what problems you were having with generated files? Did you do SET_SOURCE_FILES_PROPERTIES( generatedsource.cpp PROPERTIES GENERATED 1 ) ? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
