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
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
> 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
> 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
> 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
> 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.
> *
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
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
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
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
11 matches
Mail list logo