On 12/07/2015 11:51 PM, Bruce Stephens wrote:
On Mon, Dec 7, 2015 at 9:08 AM, Nils Gladitz <nilsglad...@gmail.com
<mailto:nilsglad...@gmail.com>> wrote:
I would avoid creating these single use, per directory libraries
entirely.
Well, creating the static libraries is obviously just an artifact of
our current
build scheme, so it makes sense to ditch it.
Creating these CMake object libraries doesn't seem bad; is there some
reason to avoid doing that? A reason for doing it is it gives targets for
target_include_directories, so just the crypto objects can be built with
the OpenSSL include directory.
While the additional object libraries will more easily allow you to have
more granular property settings they also might make it more difficult
to maintain property settings that you do want to be the same for the
entire library (especially when inheriting properties from linked targets).
Also for some reason setting the POSITION_INDEPENDENT_CODE
property for the top-level shared library (the default anyway) doesn't
seem to propagate down (and maybe it can't), and the named thing
makes it easy to apply the property to the sources. Though now I look,
I could use set_property on the sources (or the directory), and I could
use set_property similarly to add include directories (and compile
definitions).
I am not entirely sure what you mean here but it might be relevant to
point out that directory properties refer to the location
(CMakeLists.txt) where a target is defined not the location where source
files are.
Given that if you have a single target then there is only one directory
in which it is defined and from which it gets directory properties
irregardless of over how many directories the sources files may be
spread over.
A single target can build sources located in any number of
directories.
If you want to subdivide the source file listing of that one
target for organizational purposes you can do so with e.g.
include(), target_sources() and/or list variables.
Thanks for suggesting that. For some reason it hadn't occurred to me.
I'm not sure whether that would work out better for this particular case
or not, or for the larger library I'd like to do (with ~500 sources in
a tree
of ~40 directories).
The number of source files is the same irregardless of how many targets
you split them up over and the number of objects in the final link step
will stay the same as well.
But I would think that you would see improvements over the split
approach given that there are fewer superfluous intermediate steps.
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
