Re: [CMake] Antwort: Re: Re: Antwort: Antwort: Re:Antwort: Re: Toolchain with non-gcc argument format

Hi! One solution is to write a wrapper script in your favourite scripting language (Ruby, Python etc) that pretend that it's a compiler. It could recognise the -I option and start the RX compiler with the --include option. It would not hurt to make it recognise other standard flags like "-o" and "

Re: [CMake] Cannot seem to add include directory

Well, that's the standard way to add include for msbuild projects, other variables are meant to be used for the tool chain includes only Le mer. 22 nov. 2017 à 20:04, Michael Powell a écrit : > On Wed, Nov 22, 2017 at 1:45 PM, Michael Powell > wrote: > > Hello, > > > > I have a couple of librar

Re: [CMake] Cannot seem to add include directory

On Wed, Nov 22, 2017 at 1:45 PM, Michael Powell wrote: > Hello, > > I have a couple of libraries added, one SHARED and the other STATIC, > for which I want to add include directories, but they are not adding. Oh, okay... So they are being added under "additional include directories". Or they seem

[CMake] Cannot seem to add include directory

Hello, I have a couple of libraries added, one SHARED and the other STATIC, for which I want to add include directories, but they are not adding. I am trying the following: target_include_directories (${MY_PROJECT_NAME_SHARED} PUBLIC "G:/Source/Boost.Installed/boost-1.65.1/include" ) Where

Re: [CMake] spaces in generator strings troublesome (Michael Ellery)

Hi Michael Ellery thank you for your reply. > perhaps handle arguments as an array variable in bash - it?s a > slightly saner way to deal with args with spaces: > > CMDLINE=(. -G"Unix Makefiles") && cmake "${CMDLINE[@]}? Well i already got it working in bash when i wrote that. I have the para

Re: [CMake] spaces in generator strings troublesome (Konstantin Tokarev)

Hello Konstantin Tokarev, thank you for your answer. > Just write your scripts in decent language Well, i know, there are more sophisticated languages than bash. But in our environment here unfortunately there are reasons why we cannot use another language. Please do not let us discuss why. M

[CMake] Toolchain files and vcpkg

Hi! I’m trying to use packages (HPX specifically) installed with vcpkg, and according to its wiki, it is easiest to do so via the toolchain file provided by vcpkg. Here’s is what I’m doing: cd build cmake -G „Ninja” -D CMAKE_BUILD_TYPE=Release -D CMAKE_TOOLCHAIN_FILE=C:/Users/nagy-/Source/Rep

Re: [CMake] Handling of generator expressions

Dear Oleksii, indeed it works! Thank you! I have opened an issue on the CMake repository: https://gitlab.kitware.com/cmake/cmake/issues/17501 I think it could still be a bug, since target_compile_definitions and target_link_libraries seem to evaluate the expression differently. All the best, R

Re: [CMake] Using find_package() portably?

On Mittwoch, 22. November 2017 11:32:22 CET Carsten Fuchs wrote: > That is, follow-up question: near the "..." above, we have got a target > "libjpeg", but how do I get the variables JPEG_INCLUDES, JPEG_LIBRARIES > etc. that `find_package(JPEG)` normally provides so that the last line > with the `t

Re: [CMake] Using find_package() portably?

22.11.2017, 13:37, "Carsten Fuchs" : > Hi all, > > thanks to you all for your replies! > > Concluding from your replies, it seems that the following approach for > each external dependency implements a good(?) solution: > > find_package(JPEG) # without "REQUIRED" > > if (NOT JPEG_FOUND) >  #

Re: [CMake] Handling of generator expressions

UPD. forgot to CC the mailing list Hi, I am also confused by this and decided to test it. I found a long thread from 2012 that discusses list expansion issues. It doesn't tell though whether the patch was mainlined. tld

Re: [CMake] Using find_package() portably?

Hi all, thanks to you all for your replies! Concluding from your replies, it seems that the following approach for each external dependency implements a good(?) solution: find_package(JPEG) # without "REQUIRED" if (NOT JPEG_FOUND) # Optionally, under Linux only: # Stop with custom

[CMake] Antwort: Re: Re: Antwort: Antwort: Re:Antwort: Re: Toolchain with non-gcc argument format

Hi Eric, thanks a lot for your help! i'm going to try it on the dev mailing list. Cheers, Oliver Von:Eric Noulard An: oliver.za...@egoproducts.com Kopie: CMake Mailinglist Datum: 22.11.2017 09:49 Betreff:Re: Re: [CMake] Antwort: Antwort: Re:Antwort: Re: Toolchain with no

Re: [CMake] Strange error with brand new CMake 4.10.0 - SOLVED

What a shame! Actually that error message comes from my own CMakeLists.txt file - where I had so far only configured some settings for Linux and not yet for MSVC... This is indeed not any more the MT problem, but simply my own - so please forget about my previous posting! Regards, Cornelis Am Mi

[CMake] Strange error with brand new CMake 4.10.0

Yesterday I had a problem with the CMake release candidate 4 for the version 4.10.0 on Windows with MSVC 2015, and I realized by reading the CMakeOutput.log that testing the Manifest Tool (MT) was failing. And with a little Google I got the impression that this is now fixed with the final release:

Re: [CMake] Antwort: Antwort: Re:Antwort: Re: Toolchain with non-gcc argument format

Hi Olivier, Putting the list back. You may try developer list as well. 2017-11-22 9:02 GMT+01:00 : > Hi, > > Is there really no way to override this var with a toolchain file? that > seems somehow strange to me, since CMAKE is so configurable that i can't > change "-I" to "-include=" what