Without cycling dependencies you can do something like this:
/add_executable(test_object_lib_nesting main.cpp)//
//
//target_link_libraries(test_object_lib_nesting//
// second_object_lib//
// first_object_lib//
//)/
The problem I have that the linker command line will have only the
second
Hi everyone,
i'm trying to use ExternalProject_Add like the following:
set(BOOST_VERSION 1.68.0)
set(BOOST_VERSION_NODOTS 1_68_0)
set(BOOST_URI
https://dl.bintray.com/boostorg/release/${BOOST_VERSION}/source/boost_${BOOST_VERSION_NODOTS}.tar.gz)
set(BOOST_HASH 5d8b4503582fffa9eefdb9045359c239)
Hi everyone,
i'm trying to get the boost library working with cmake and
externalproject_add:
https://paste.debian.net/1082645/
best regards!
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various
Hi Richard,
does it help if you specify the linking as PUBLIC? I.e.:
target_link_libraries(second_object_lib PUBLIC first_object_lib)
Petr
On Wed, 22 May 2019 at 07:48, Richard Szabo wrote:
> Hi cmakers
>
> I'm trying to get the following example working:
> ```
> cmake_minimum_required(VERSIO
This is a known limitation of the current design. Only directly linked
object library objects are propagated.
For more details on why see: https://gitlab.kitware.com/cmake/cmake/issues/18090
On Wed, May 22, 2019 at 1:48 AM Richard Szabo wrote:
>
> Hi cmakers
>
> I'm trying to get the following e
Hello,
i have some problems with cross compile for android.
i need to build libssh for android.
If i run CMake like:
cmake .. -DCMAKE_SYSTEM_NAME=Android
-DCMAKE_ANDROID_STANDALONE_TOOLCHAIN=/home/da/Android/standalone-toolchain-4.9
-DCMAKE_SYSTEM_VERSION=21
i get the following error:
-mtune=x
Previous versions of CMake GUI (prior to CMake 3.14) always displayed
the name of the selected platform (typically "Win32" or "Win64") with
the current generator, for example:
"Current Generator: Visual Studio 14 2015 Win64"
It was very convenient to have the platform name displayed on the m
>From the command line, I want to generate Ninja build scripts that
utilize a specific version of MSVC compiler. Basically I'd like the
combination of `-G"Visual Studio 15 2017"` with regards to its ability
to find the C and C++ compiler on the system via registry/environment
variables, and `-G"Nin
You can run `CMake -GNinja ` in a visual studio
command line prompt where It could find the right C/C++ compiler via the
environment. Normally you can find the command line prompt in the windows
menu.
On Wed, May 22, 2019 at 9:58 AM Robert Dailey
wrote:
> From the command line, I want to generat
The easiest way is to launch a CMD with the correct development environment
(see for example
https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs).
Le 22 mai 2019 à 15:58 +0200, Robert Dailey , a écrit
:
> From the command line, I want to generate Ninja build
Do this all the time both for our CDash nightlies and when I am developing on
Windows. The essential pieces of the puzzle are the following:
1: Ninja needs to be on your path
2: The compilers need to be on your path.
1 can be solved in a few different ways. The brute force is to edit the system
On Wed, May 22, 2019 at 10:27 AM Michael Jackson <
mike.jack...@bluequartz.net> wrote:
> Do this all the time both for our CDash nightlies and when I am developing
> on Windows. The essential pieces of the puzzle are the following:
>
> 1: Ninja needs to be on your path
> 2: The compilers need to b
> On May 22, 2019, at 6:58 AM, Robert Dailey wrote:
>
> From the command line, I want to generate Ninja build scripts that
> utilize a specific version of MSVC compiler. Basically I'd like the
> combination of `-G"Visual Studio 15 2017"` with regards to its ability
> to find the C and C++ compi
Can you submit this to our issue tracker please (
https://gitlab.kitware.com/cmake/cmake/issues )
On Wed, May 22, 2019 at 9:44 AM Niels Dekker
wrote:
>
> Previous versions of CMake GUI (prior to CMake 3.14) always displayed
> the name of the selected platform (typically "Win32" or "Win64") with
>
Thanks for your support, Robert! Here it is:
#19290 "Visual Studio platform name Current Generator back on CMake
GUI window?"
https://gitlab.kitware.com/cmake/cmake/issues/19290
Kind regards, Niels
On 2019-05-22, Robert Maynard wrote:
Can you submit this to our issue tracker please (
htt
How about using the same build directory?
Am 22. Mai 2019 18:02:28 MESZ schrieb "Agata Krasoń" :
>Hello,
>
>I am trying to build from source an application.
>I add in cmake-gui : XIOT_INCLUDE_DIR - path do include dir
>When I compile on linux ...
>It gives me an error:
>
>[image: Screenshot_20190
Thanks everyone. I fully understand about compilers being on PATH or
setting the CMAKE__COMPILER variables. However, what is really
important is the system introspection done by CMake to find the IDEs
when you select the visual studio generators. I was hoping that logic
could be shared. This would
Cool tip. Didn’t know that. I should compact my script a bit. I do that for the
Intel Fortran compiler that we use but didn’t think of it for the vcvarsall.bat
file.
--
Mike Jackson
From: Juan Sanchez
Date: Wednesday, May 22, 2019 at 11:41 AM
To: Michael Jackson
Cc: Robert Dailey , CM
With Public it is still the same problem :(
cmake_minimum_required(VERSION 3.14)
project(test_object_lib_nesting)
set(CMAKE_CXX_STANDARD 14)
add_library(first_object_lib OBJECT first.cpp)
add_library(second_object_lib OBJECT second.cpp)
target_link_libraries(second_object_lib PUBLIC first_obje
The reason going to object libs instead of static libs is the
limitation of windows dynamic libraries that export simbols must be in
the liner command line object it can not be added to the static
libraries linked to the dlls.
with gcc this problem can be solved with
-Wl,--whole-archive
libs
20 matches
Mail list logo
