I believe that your targets should be using something like:
target_compile_options(yourlib PRIVATE -Wwhatever)
They will be built with said warnings, but it won't be propagated to
consumers of the library. So you shouldn't have to remove anything.
On Tue, Apr 9, 2019 at 8:47 AM Benjamin Orgogozo
On 29/11/2017 12:02, Johannes Zarl-Zierl wrote:
Hello Carsten,
On Samstag, 25. November 2017 11:46:44 CET Carsten Fuchs wrote:
Thanks for your reply, but how can I proceed from here?
In order to be able to write in the parent script something that works
in either case, that is,
target_link_li
Which version of CMake and Ninja are you using?
It seems like you are trying to reimplement what has been added in CMake
3.9. Quote from the changelog:
The Ninja generator has loosened the dependencies of object compilation.
Object compilation now depends only on custom targets and custom
com
On 01/09/2017 20:40, Alex Turbov wrote:
Hi Robert,
On Fri, Sep 1, 2017 at 9:21 PM, Robert Dailey
mailto:rcdailey.li...@gmail.com>> wrote:
One problem I thought of with the former (one big target.cmake with
all import targets in there) is that if you only ask for a subset of
comp
If they were not propagated, it wouldn't compile at all, so they're
definitely there somewhere.
Can you show your CMakeLists.txt files?
/Florent
On 12/07/2017 19:59, Christian Mazakas wrote:
To give a brief overview of what I'm trying to do, right now I'm
working on a project with tests. I wa
From what I've read from the VS CMake team at Microsoft in various blog
posts and online discussions, they plan to have actual targets someday
in VS instead of the "Open folder" structure they currently have with
their integration. So right now, that information wouldn't be of any use
for them
On 20/05/2017 13:32, Urs Thuermann wrote:
Yes, but not directly. The executable depends on the object file, and
the object file depends on the (created) source file. Since "depends
on" is transitive, the executable also depends on the source file.
Still, I would prefer to write add_executable(f
rote:
>
>> One option may be a superbuild arrangement (based on ExternalProject,
>> online searches should give you details). The only thing the top level
>> would do is setup the sub builds, including downloading and selecting which
>> toolchain(s) to use for each s
It is possible.
Nothing prevents you from calling execute_process to download as extract
your toolchain file when it is run. You probably want to check the
destination folder for a pre existing download though.
Then, you proceed on configuring Cmake to use it as usual.
/Florent
On Apr 17, 2017
On 30/03/2017 04:38, Robert Dailey wrote:
At the end of the day, I've solved the Boost problem but I have many
other libraries I still manually build: openssl, libpng, zlib, etc.
It's as you said, maintaining build scripts for all of these will be
challenging but I think that's the proper way to
On 30/03/2017 03:54, Robert Dailey wrote:
On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli
wrote:
This is known as "super build".
Yes, this is exactly why I made my Boost CMake build scripts, which you use
unless you changed your mind today :)
You mean this?
https://github.com/Or
On 30/03/2017 02:10, Robert Dailey wrote:
Interested in hearing everyone's thoughts on this idea of mine.
Right now I have several third party libraries: openssl, boost,
libpng, zlib, etc. List goes on. I need to support these libraries on
at least 3 different platforms: ARM android, x86 linux,
Use add_subdirectory(... EXCLUDE_FROM_ALL) to prevent anything in there to
be installed by default.
I had the issue in one project and it did fix it for us.
Also, 3rdparty libraries should be tagged like that anyway to be built only
when they are used by the main targets.
/Florent
On Feb 16, 20
You can either unpack the target at generation time (recommended).
Or you could create an INTERFACE target instead.
The first solution is recommended as I believe it's important to have
access to all the sources (for IDEs for example) before actually
starting the build process.
/Florent
On 1
On 31/01/2017 23:34, Craig Scott wrote:
If you need to set CCACHE_DIR as an environment variable, then my
previous email shows how to embed that in the launcher script, which
will work for both Xcode and Linux (since the same launcher script is
ultimately being invoked for both cases). All th
I've had to deal with this in the past.
For glibc, it's more tricky since when you compile on a newer
distribution, it will automatically use the newer version of some
symbols. Some functions have had breaking changes and to keep
compatibility, they kept all the different version in the binary
I'm pretty sure that the toolchain bundled with the NDK, made by Google,
hasn't been tested with other generators than Ninja or possibly Make.
Also, there are some known bugs with it, including the one related to
CMAKE_CXX_STANDARD (see
https://code.google.com/p/android/issues/detail?id=227915 a
You don't compile a header only library (unless you're talking about
precompiled headers, which I think you don't).
What you need is compiling the sources using it as Objective C.
Which is a matter of adding target_compile_options( PRIVATE
"-ObjC") on the target with the sources if I remember c
18 matches
Mail list logo
