[CMake] Shared library from sources in several subdirectories

[Nils Gladitz]

On 12/07/2015 11:51 PM, Bruce Stephens wrote:
>
> On Mon, Dec 7, 2015 at 9:08 AM, Nils Gladitz <nilsgladitz at gmail.com 
> <mailto:nilsgladitz at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20151208/82aa0efd/attachment-0001.html>