Hi, all,
I try to use some gcc link option and libs(except libs link by
target_link_libraries(...)), i researched and try to use
'CMAKE_EXE_LINKER_FLAGS' in a simple project, as below:
in dir, there are 5 files:
-hello.h
-hello.c
-main.c
-hello.o
-libhello.a
hello.o was compiled by hello.c(gcc -
CMake (version 3.5.2) surprised me with how it's passing values to
sub-projects, so I was wondering if this is expected behavior. Here's an
example of what I mean. Let's say I have a project Foo in a directory of
the same name. It contains a third-party library called Bar which has a
CMakeLists.txt
Hi Doug,
your syntax for `set()` in Foo is incorrect; you're actually setting a
non-cache variable OPT1 do the value "ON;FORCE".
You want to set the *cache* variable OPT1, which would be done like this:
set(OPT1 ON CACHE BOOL "Set to OFF|ON (default is OFF) to control build
of Bar library" FOR
Hi Petr,
Thank you so much. I'll try it when I get in to work this morning.
Doug
On Fri, May 20, 2016 at 5:37 AM, Petr Kmoch wrote:
> Hi Doug,
>
> your syntax for `set()` in Foo is incorrect; you're actually setting a
> non-cache variable OPT1 do the value "ON;FORCE".
>
> You want to set the *c
You don't have to create a cache variable for this. Put yourself in the
position of CMake;
* While scanning the CMakeLists.txt of Foo CMake encounters the set(OPT1 ON
FORCE) command, which tells CMake to create a *variable* called OPT1 with
value ON
* Then CMake is asked to include Bar
* While scan
The situation already involves a cache variable, though: `option(abc "cmt"
ON)` is just syntactic sugar for `set(abc ON CACHE BOOL "cmt")`.
Petr
On 20 May 2016 at 13:03, Jakob van Bethlehem
wrote:
> You don't have to create a cache variable for this. Put yourself in the
> position of CMake;
> *
Ah, nice. Good to know. But then still that cache variable is not created
until *after* it was set by Foo, because it is only created when adding the
Bar subdirectory, which explains the output.
Sincerely,
Jakob
On Fri, May 20, 2016 at 1:18 PM, Petr Kmoch wrote:
> The situation already involve
Is there a reason to not use target_link_libraries here? For the purposes
of your example there's no reason to be using CMAKE_EXE_LINKER_FLAGS. What
are you actually trying to accomplish? Because there is almost certainly a
better way to achieve your desired result than via CMAKE_EXE_LINKER_FLAGS.
Nice to see you again, Mr. Atkins. I was trying to add a very long gcc link
option to a ELF file, there are some options, like -whole-archive，
-rpath，and i don't known how to set in CMake, so i decided to use original
gcc option, is there better way to solve this?
Chuck Atkins wrote
> Is there a r
Petr - using:
set(OPT1 ON CACHE BOOL "Set to OFF|ON (default is OFF) to control build
of Bar library" FORCE)
works like a champ!
Jakob - Thanks for the suggestion, but I can't put "add_subdirectory(Bar)"
before setting the variable(s) in Foo's CMakeLists.txt, because cmake
finishes configuri
> -rpath
RPATHs are automatically added by CMake to executables so they can use
libraries from the build tree.
> -whole-archive
>
whole-archive is definitely trickier since you shouldn't be applying it to
the entire executable but instead wrapping individual libraries with it.
Conveniently,
I'm using CMake 3.5.2 generating for Linux / OSX / Visual Studio.
I'm creating a shared library. This shared library is constructed
mostly from other libraries (which are also built in other directories
by this cmake setup).
I have been doing this for a long time and it worked fine:
add_libra
On Fri, 2016-05-20 at 11:58 -0400, Paul Smith wrote:
> This is not nice but it does work...
Gah! The last of my problems can be solved with add_dependencies().
Somehow I didn't see this and was looking through all the target
properties with set_properties() to find a way to add a dependency...
si
Just discovered a bug in the Xcode generator; this works fine with
Makefile generator (on OSX or Linux) and Visual Studio, but fails on
Xcode:
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.5)
project(BadXcode)
add_library(obj OBJECT foo.cpp)
add_library(shared SHARED $)
$ touc
On Fri, 2016-05-20 at 14:34 -0400, Paul Smith wrote:
> Just discovered a bug in the Xcode generator; this works fine with
> Makefile generator (on OSX or Linux) and Visual Studio, but fails on
> Xcode:
Meh. Looks like this is documented in add_library():
> Some native build systems may not like
I've got a project with a number of target platforms, including some that I
have to cross-compile to such as android, that uses protobuf. If you're
unfamiliar, the crux of the issue is that there is both a library,
libprotobuf, and an 'compiler', protoc, that takes .proto files and
generates a .h/.
A small addendum - The way I am currently solving this problem is by
replacing the version of protoc in the library folder for android with one
that works on the host machine, but this is really not the best since it
means that the library distribution is tied to the host AND the target.
Thinking
Hi,
Did you read the Wiki page about cross compiling with CMake? CMake can already
restrict searching for libraries to certain directories when cross compiling.
HS
Am 21. Mai 2016 04:13:38 MESZ, schrieb Walter Gray :
>A small addendum - The way I am currently solving this problem is by
>replac
18 matches
Mail list logo
