Thank you, Eric and Ugesh,
Am Mi., 31. Juli 2019 um 09:16 Uhr schrieb Eric Doenges :
> My experience has been that find_file and friends behave in unexpected
> ways when you set CMAKE_SYSROOT. In our toolchain files, we set
> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> set(CMAKE_FIND_ROOT_PATH
Hello all,
I'm trying to adapt my CMake based toolchain to Android and I'm noticing
very strange behavior that I'd like to ask about.
My toolchain is C++ based with some dependencies such as Boost, OpenSSL or
protobuf. So far it works on a variety of platforms such as Windows (MSVC),
several Linux
Hello List,
On Fri, Apr 12, 2019 at 6:13 PM Stephan Menzel
wrote:
>
> I guess the answer really lies in ‘why those 3?’ At first I thought it
> would be dependencies among the imported targets but I did depend on them
> directly. Also, the error is thrown before I create any targe
> On 12. Apr 2019, at 17:48, Michael Ellery wrote:
>
> oh, sorry I misunderstood. How did you build/install boost on windows
All ‘normal’ boostrap, build. With tagged filenames. Files look very much like
I expect them to look. This will actually be the 50th boost version I’ll be
using so I th
Hello Michael,
thanks for your response.
On Fri, Apr 12, 2019 at 4:02 PM Michael Ellery wrote:
> whenever I use bleeding-edge boost, I try to grab the latest FindBoost:
> https://github.com/Kitware/CMake/commits/master/Modules/FindBoost.cmake
>
> ..in particular, you probably want
> https://git
Hello List,
Boost 1.70.0 was just released and I'm integrating it into our projects. I
notice FindBoost doesn't do the trick on Windows (MSVC141) anymore, on
Linux / G++ it works fine. Here's what I do:
set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_
Hello Francis,
On Thu, Apr 4, 2019 at 6:49 PM Francis Giraldeau <
francis.girald...@gmail.com> wrote:
> Maybe the problem is related to Cotire? I see that it is used in
> mredis. I tried to reproduce the issue, and it behaves correctly. You
> might want to try to reproduce using the following min
Hello Paul and Shoaib,
I'm answering to the both of you.
On Thu, Apr 4, 2019 at 7:13 AM Paul Smith wrote:
> Now although I don't understand the exact reasons behind that, over the
> years came to accept that depedencies between the lib and the resulting
> artifcats are not working. Like, when I
y this isn't possible I may be able to better craft a workaround
on my own.
Really, anything helps. I am losing time and nerve every day because of
this and have been paying this price for so many years that I think it
really is time to come up with a solution.
Cheers,
Stephan
On Tue, Ap
Hello List,
In our projects we are using static linkage on Windows (MSVC) and Linux. A
number of static libs are created and then linked into executables, such as
unit tests, tools and the actual production artifacts. Very normal stuff.
add_library(mylib STATIC mysources)
add_excecutable(mytest m
On Sat, Oct 6, 2018 at 10:58 AM Stephan Menzel
wrote:
>
> protobuf_generate(TARGET my_protobuf_lib)
>
>
Well, it seems like this was the culprit all along. There is a bug in
protobuf's usage of the add_custom_command. Appears this is known and fixed
by:
https://github.co
Hello all,
I am a long term user of CMake, protobuf and grpc on Windows (MSVC15) and
Linux.
Roughly in the beginning of this year I started to notice that dependencies
of targets using generated sources to their appropriate protobuf files
didn't work anymore. Basically, when I change a grpc source
On Thu, Jun 28, 2018 at 4:07 PM Stephan Menzel
wrote:
> I am observing a strange problem regarding dependencies to static libs in
> executables. I am not entirely sure but it seems this started since I
> upgraded to the 3.11 line. I am using Windows and MSVC14.
>
> Basicall
Hello Innokentiy,
On Thu, Jun 28, 2018 at 4:17 PM, Innokentiy Alaytsev
wrote:
> Hello!
>
> I hope you will forgive me a silly question: did you consider checking last
> change date of the executable? And is there any way you can ensure that the
> changes to the library a present in the executabl
Hello CMake community,
I am observing a strange problem regarding dependencies to static libs in
executables. I am not entirely sure but it seems this started since I
upgraded to the 3.11 line. I am using Windows and MSVC14.
Basically, my code base contains a number of static libraries that are
l
On Tue, Nov 8, 2016 at 4:21 PM, wrote:
>
> If you are going to use /MD instead of /MDd, then you probably also need
> to remove the _DEBUG preprocessor flag.
> IIRC, I've seen cases where defining _DEBUG includes symbols only
> defined by the debug runtimes.
>
> Clint
>
What a surprise. Removing
Hello everyone,
I'm looking for a way to force Debug configurations in generated MSVC
solutions to use the Release runtime instead of the default "Debug". e.g.
/MD rather than /MDd.
My use case is an ever recurring problem of creating libraries that are
linked in plug-in fashion against Release o
Hey all,
I have a few more findings about this before I finally give up and resort
my old self made approach: It looks to me like the imported target
mechanism is not propagating properties the way it could and probably
should. Es specially not like it is described here:
https://cmake.org/cmake/he
I have investigated further into this and still have no solution, but a
hint, which anyone may be able to confirm.
It appears like I was led astray by a number of bugs in
target_link_libraries() which I was mistaking for intentional behavior and
so I started to re-create the behavior manually. Whi
Hello,
I am trying to have config dependent link. Basically, coming from a set of
3rd party location scripts I have a Visual Studio target which I would like
to equip with imported libs rather than the existing "manual" scripts. With
that I have a few trouble that maybe someone can help me with.
Hello,
I am currently bringing a rather complex CMake based build system up to
speed with current versions and hope to get rid of old quirks and
workarounds. One of which being the way I have to amend version information.
It is primarily used in a MSVC11 scenario and contains a number of macros
t
Hi Philip,
On Sun, Jan 17, 2010 at 8:01 AM, Philip Lowman wrote:
> Thanks for adding the 64-bit support. I will merge it in soon but
> before I do I just wanted to confirm that the path for the 64-bit
> libraries is "msvc/x64/Debug" & "msvc/x64/Release" regardless of if
> the MD or MT project fi
I guess it would be a C linkage problem then.
Have you got extern "C" {} around the exported symbols?
Cheers,
Stephan
On Sat, Jan 16, 2010 at 7:21 PM, Yixun Liu wrote:
> I do add test.c (see previous email).
> If I change test.c to test.cxx, it works. I do not know why.
>
__
Hi,
please correct me if I'm wrong but in my impression the existing
FindGTest module is rather ignorant about finding 64 bit builds on
windows. It also doesn't handle Debug/Release linking very well. Also
it appears not to be quite consistent with it's API description.
Please find a patch attache
Hello,
I'd like to create a custom doxygen target for a project. The relevant parts
look like that:
/
doc/Doxyfile.in
lib/[files with all the documentation]
build/
CMakeLists.txt
Now what I'd like to have is a doxygen target where I can do something like
this:
$ cd build
$ cmake ..
25 matches
Mail list logo
