ymore. So I worked around this by converting "barstatic" into
an object library, but it feels ugly.
Why would CMake require exporting statically linked dependency targets among
the targets that use them? Feels like a bug to me...unless someone can explain
why :)
Regards,
-Lassi Niemistö
--
P
Hello,
It seems CMake has a special handling for system header dependencies. I.e. if
my .c file includes /usr/include/someheader.h, modifying the someheader.h does
not cause the .c file to be rebuilt.
How to work around this issue? We have some custom libraries that get installed
to system
Hello,
I spent a lot of time figuring out how to support multiple compilers in
parallel. Here is how I did it:
·Write a toolchain file for each of your compiler setups. Specify any
toolchain specific compiler flags there. See
it
works only when the shared lib has at least one extra source file compared to
the static version. Or, worked until the export stage.
-Lassi
From: Marc CHEVRIER
Sent: torstai 28. helmikuuta 2019 11.37
To: cmake-developers@cmake.org; Lassi Niemistö
Subject: Re: [cmake-developers] Mandatory export
from "barstatic" were not available for users
of "fooshared" anymore. So I worked around this by converting "barstatic" into
an object library, but it feels ugly.
Why would CMake require exporting statically linked dependency targets among
the targets that use
> For your use case, CMake does have logic to generate -rpath-link flags to
> find dependencies of linked shared libraries, but it needs to know about
> these dependencies.
> Here is how to handle this:
> * Tree1 creates an imported target `extlib`.
> It is *not* installed or exported.
> *
PUBLIC_WITHIN_BUILDTREE a bit similar to defining include dirs for build and
install separately using a generator expression.
Sorry for the hassle and thanks ☺
-Lassi
From: Marc CHEVRIER
Sent: torstai 28. helmikuuta 2019 12.20
To: cmake-developers@cmake.org; Lassi Niemistö
Subject: RE: [cmake-developers
> Please post a minimal example tarball showing your case in practice.
https://gitlab.com/lassi.niemisto/cmake_import_case
Instruction:
* run the test.sh script, it will copy the test setup under /tmp/ and operate
it there
* by default everything should pass
* go to
> The file `cmake_test_system_lassi/tree1/Tree1Config.cmake` should have code
> to re-create the extlib imported target
> with whatever usage requirements it had for building tree1. See the patch
> below.
> In combination with removing all the `extlib_interface` code, the `test.sh`
> script
> We have not thought deeply through the semantics of that in general.
> One of the main challenges is relocation handling. Targets installed by the
> project have known locations relative to the install prefix and we expect
> that everything gets relocated together. Targets from external
l of "lib1" to fail due to their PUBLIC
linkage
Am I just missing something and should be able to install the export of
"extlib" without installing the target itself? Any reasoning why imported
targets should not be possible to export? Any other solution ideas for passing
th
11 matches
Mail list logo
