From d3ck0r at gmail.com  Sun Sep  1 00:56:05 2019
From: d3ck0r at gmail.com (J Decker)
Date: Sat, 31 Aug 2019 21:56:05 -0700
Subject: [CMake] ExternalProject_Add Visual Studio build Install Target
In-Reply-To: <CAA2GJqXZz2K-SoksbRAfuo+PmYPfmOzAfUe0S_3mgo-rQq-B9Q@mail.gmail.com>
References: <CAA2GJqXZz2K-SoksbRAfuo+PmYPfmOzAfUe0S_3mgo-rQq-B9Q@mail.gmail.com>
Message-ID: <CAA2GJqWQ7NWWoH39hCPvLJ_ZKRxReXoEyTCDTGVPNfdyey6+TA@mail.gmail.com>

Why does it seem I'm the only one with this problem?
I've recently updated this other portable system while I'm on the road, and
the latest version of course fails the same way.

---- The Current build output

1>------ Build started: Project: intershell
(ExternalProjectTargets\intershell\intershell), Configuration:
RelWithDebInfo x64 ------
1>  Performing install step for 'intershell'
1>  Microsoft (R) Build Engine version 14.0.23107.0
1>  Copyright (C) Microsoft Corporation. All rights reserved.
1>
1>MSBUILD : error MSB1009: Project file does not exist.
1>  Switch: install
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

-----
share\cmake-3.15\Modules\ExternalProject.cmake
line 1853

      if(step STREQUAL "INSTALL")
        list(APPEND args --target install)
      endif()


Change to
      if(step STREQUAL "INSTALL")
        list(APPEND args --target INSTALL)
      endif()

 -------------------

And then the output looks like
 --------------
1>------ Build started: Project: intershell
(ExternalProjectTargets\intershell\intershell), Configuration:
RelWithDebInfo x64 ------
1>  Performing install step for 'intershell'
1>  Microsoft (R) Build Engine version 14.0.23107.0
1>  Copyright (C) Microsoft Corporation. All rights reserved.
1>
1>    InterShell.Service.vcxproj ->
M:\javascript\sack-gui\build\sack-src\src\intershell-build\service.shell\RelWithDebInfo\InterShell.Service.exe
..........
(completes successfully )



On Thu, Apr 25, 2019 at 1:27 AM J Decker <d3ck0r at gmail.com> wrote:

> I've had to make this modification the last few versions...
>
> cmake/share/cmake-3.14/Modules/ExternalProject.cmake
>
> line 1870 from
>
>       if(step STREQUAL "INSTALL")
>         list(APPEND args --target install)
>       endif()
>
> to
>
>       if(step STREQUAL "INSTALL")
>         list(APPEND args --target INSTALL)
>       endif()
>
> Otherwise, when building with visual studio, and trying to run the
> <project>-install.rule  rule, it says 'no such project'
>
> I don't think the same issue happens when building from the command line.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190831/738e2b6c/attachment.html>

From thomas.tornblom at iar.com  Mon Sep  2 05:05:41 2019
From: thomas.tornblom at iar.com (=?UTF-8?Q?Thomas_T=c3=b6rnblom?=)
Date: Mon, 2 Sep 2019 11:05:41 +0200
Subject: [CMake] How to avoid escaping $?
Message-ID: <b03249c0-c440-89f6-54b6-f3074f91e915@iar.com>

I have a need to add an argument like "-DImage$$= " to a compile 
command, i.e. define a macro Image$$ to just expand to a single space 
character.

I'm using Windows 10? and I configure my project to use Unix Makefiles 
for building. cmake appears to use "sh" (bash) to execute the build 
commands, and I have this in one of my cmake files:
---
 ??? function(config_setting_shared_compiler_flags tgt)
 ??? ??? embedded_set_target_compile_flags(TARGET ${tgt} LANGUAGE C 
FLAGS ${COMMON_COMPILE_FLAGS} "-DImage$$= " "-DLoad$$LR$$= " 
"-D$$ZI$$Base=$$Base" "-D$$ZI$$Limit=$$Limit" "-D$$RO$$Base=$$Base" 
"-D$$RO$$Limit=$$Limit" "-D_DATA$$RW$$Base=_DATA$$Base" 
"-D_DATA$$RW$$Limit=_DATA$$Limit" "-D_DATA$$ZI$$Base=_DATA$$Base" 
"-D_DATA$$ZI$$Limit=_DATA$$Limit" "-D_STACK$$ZI$$Base=_STACK$$Base" 
"-D_STACK$$ZI$$Limit=_STACK$$Limit" )
 ??? endfunction()
---

When doing a verbose build I see that the relevant part of the command 
lines expands to:
---
"-DImage\$\$= "
---
I.e. cmake has escaped the dollar signs with a \, which is what a normal 
unix shell needs, and this works fine on my system.

We've tried to build this project on a system with Windows 7, which has 
no working bash, and it uses cmd.exe to run the build lines. cmd.exe 
does not handle the \ escape the way bash does so the the build fails.

cmd.exe accepts the following syntax:
---
"-DImage$$= "
---

So no need to escape the dollar signs.

Is there a way to stop cmake from escaping dollar signs in this case?

/Thomas


From craig.scott at crascit.com  Mon Sep  2 07:14:34 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Mon, 2 Sep 2019 21:14:34 +1000
Subject: [CMake] Excluding targets from install set
In-Reply-To: <fc211ee7-e9fd-dd9e-6f2b-379cf96b29e7@vires.com>
References: <fc211ee7-e9fd-dd9e-6f2b-379cf96b29e7@vires.com>
Message-ID: <CA+dygYkEx_dDBmEiNxe4R=T6UKqCNnfNb3j6NubeRdP6xq1d5w@mail.gmail.com>

On Tue, Jul 23, 2019 at 7:04 PM Gordon Koefner <gordon.koefner at vires.com>
wrote:

> Hi all!
>
> We have been migrating our buildsystem to CMake and are trying to use
> the `install` command to deploy different parts of the software.
> However `make install` also installs artifacts from our dependencies,
> internal as well as 3rd party, that are unnecessary/unwanted.
>
> Is there a native way to exclude certain subdirectories or build targets
> from the install set? The only solution I could think of is to manually
> add an option, e.g.:
>
> option(${TARGET_NAME}_INSTALL on "") # on by default
> if(${TARGET_NAME}_INSTALL)
>     install(...)
> endif()
>
> Maybe the culprit is also that we are using find_path and
> add_subdirectory to add any internal dependencies we have to the build
> tree - I am starting to think that this is a mistake.
>
> I have read about ExternalProject - but I am unsure whether this is the
> correct way to go about it but it does allow modification of another build.
>
> How do you guys solve this issue, how can I define which dependencies I
> want installed?
>
> I really want to avoid writing a shellscript to filter out any unwanted
> stuff.
>


A bit late, but clearing my inbox and found this one still unanswered. ;) I
typically handle this situation by defining install components for my own
part of the build (i.e. including COMPONENT options with my install()
commands). Then when I want to make packages, I populate
CPACK_COMPONENTS_ALL with just those components I want included. All
dependencies are part of the build (using FetchContent), it's just that I
don't add their install components to my list so they are left out. I don't
do a bare "make install", I always create packages, so this works for me.
If you did want to do an install directly, you could use the new "cmake
--install" functionality added in CMake 3.15 which supports specifying the
component to install. The end of the documentation page for the install()
command also shows another way to install components selectively (under the
heading Generated Installation Script).

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190902/51bd14e3/attachment.html>

From seblu at seblu.net  Tue Sep  3 08:38:31 2019
From: seblu at seblu.net (=?ISO-8859-1?Q?S=E9bastien?= Luttringer)
Date: Tue, 03 Sep 2019 14:38:31 +0200
Subject: [CMake] Variable expansion to positional arguments
Message-ID: <2b93360bd32f431dfeb967fd761b28b76d059824.camel@seblu.net>

Hello,

I'm trying to improve some functions by wrapping them. I found the topic asked
several times in different places and time [1][2][3]. This article[4] explain
very well the current situation and issues.

My understanding is, there is _no_ solution to correctly expand variables to
positional arguments with cmake. Which make passing dynamic arguments
unreliable.
Am I correct? Is this a feature or a bug?

Regards,

[1] https://stackoverflow.com/questions/52480737/pass-empty-strings-in-cmake
[2] https://cmake.org/pipermail/cmake-developers/2015-July/025640.html
[3] https://cmake.org/pipermail/cmake/2013-October/056024.html
[4] https://crascit.com/2019/01/29/forwarding-command-arguments-in-cmake/

-- 
S?bastien "Seblu" Luttringer


From seblu at seblu.net  Tue Sep  3 08:31:14 2019
From: seblu at seblu.net (=?ISO-8859-1?Q?S=E9bastien?= Luttringer)
Date: Tue, 03 Sep 2019 14:31:14 +0200
Subject: [CMake] Variable expansion to positional arguments
Message-ID: <52954f62f0a2a7d38816ce7daac79802992d2d8c.camel@seblu.net>

Hello,

I'm trying to improve some functions by wrapping them. I found the topic asked
several times in different places and time [1][2][3]. This article[4] explain
very well the current situation and issues.

My understanding is, there is _no_ solution to correctly expand variables to
positional arguments with cmake. Which make passing dynamic arguments
unreliable.
Am I correct? Is this a feature or a bug?

Regards,

[1] https://stackoverflow.com/questions/52480737/pass-empty-strings-in-cmake
[2] https://cmake.org/pipermail/cmake-developers/2015-July/025640.html
[3] https://cmake.org/pipermail/cmake/2013-October/056024.html
[4] https://crascit.com/2019/01/29/forwarding-command-arguments-in-cmake/

-- 
S?bastien "Seblu" Luttringer


From sancelot at numalliance.com  Tue Sep  3 09:05:03 2019
From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=)
Date: Tue, 3 Sep 2019 15:05:03 +0200
Subject: [CMake] Finding custom qmake path
Message-ID: <cf029bc9-6263-4dde-4904-fc759406f167@numalliance.com>

Hi,

Is there a way to find qmake path of a custom setup in order using it an 
add_custom_command

my QT5 path is available in CMAKE_PREFIX_PATH.


Regards,,

S.Ancelot


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190903/8430e969/attachment.html>

From sancelot at numalliance.com  Tue Sep  3 09:36:04 2019
From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=)
Date: Tue, 3 Sep 2019 15:36:04 +0200
Subject: [CMake] Finding custom qmake path
In-Reply-To: <cf029bc9-6263-4dde-4904-fc759406f167@numalliance.com>
References: <cf029bc9-6263-4dde-4904-fc759406f167@numalliance.com>
Message-ID: <1bc0e260-e1e7-5730-ef63-05937ed648a1@numalliance.com>

I solved it using

|get_target_property (QT_QMAKE_EXECUTABLE Qt5::qmake IMPORTED_LOCATION)|


Le 03/09/2019 ? 15:05, St?phane Ancelot a ?crit?:
>
> Hi,
>
> Is there a way to find qmake path of a custom setup in order using it 
> an add_custom_command
>
> my QT5 path is available in CMAKE_PREFIX_PATH.
>
>
> Regards,,
>
> S.Ancelot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190903/9aefd54e/attachment.html>

From edo.paskino at gmail.com  Wed Sep  4 05:55:23 2019
From: edo.paskino at gmail.com (Edoardo Pasca)
Date: Wed, 4 Sep 2019 10:55:23 +0100
Subject: [CMake] external project CONFIGURE_COMMAND adds quotation to
 arguments
Message-ID: <CAJZDnTj=m8NoDYk=XpnokFv6OtCGc5EydLi2zW4+bBsqTzEi9g@mail.gmail.com>

Dear all,

I'm using ExternalProjectAdd to build an external package.

On the CONFIGURE_COMMAND I have to pass some variables to the configure
script in this form:

configure CPPFLAGS="-I/dir/include -L/dir/lib"

To do this I use

CONFIGURE_COMMAND ${CMAKE_COMMAND} -E env ${CMAKE_BINARY_DIR}/configure
CPPFLAGS="-I/dir/include -L/dir/lib"

However, when cmake issues that command (you can see that with make
VERBOSE=1) it wraps the CPPFLAGS parameters with quotation marks (as below)
and the configure script fails

configure "CPPFLAGS=\"-I/dir/include -L/dir/lib\""

Below you can find a minimal CMakeLists.txt to test this.

I'd appreciate any help on how I'd remove those quotation marks.

Thanks

Edo



cmake_minimum_required(VERSION 3.9.0)

project(libACE)
include(ExternalProject)

#create a configure script
file(WRITE ${CMAKE_SOURCE_DIR}/configure
"
#! /bin/bash

echo $0 received $# parameters

for arg
do echo $arg
done
")
file(COPY ${CMAKE_SOURCE_DIR}/configure
     DESTINATION ${CMAKE_BINARY_DIR}
     FILE_PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ)
ExternalProject_Add(
  external_test
  GIT_REPOSITORY https://github.com/paskino/libace-conda
  GIT_TAG origin/master

  CONFIGURE_COMMAND ${CMAKE_COMMAND} -E env ${CMAKE_BINARY_DIR}/configure
NVCCFLAGS="-Idir -Ldir" CPPFLAGS="-Idirc -Ldirl"

  BUILD_COMMAND ""
  INSTALL_COMMAND ""

  LOG_INSTALL 1
  BINARY_DIR ${CMAKE_BINARY_DIR}/build/
  INSTALL_DIR ${CMAKE_BINARY_DIR}/install
  STAMP_DIR ${CMAKE_BINARY_DIR}/stamp
  TMP_DIR ${CMAKE_BINARY_DIR}/tmp
  DOWNLOAD_DIR ${CMAKE_BINARY_DIR}/download
  SOURCE_DIR ${CMAKE_BINARY_DIR}/source
)

-- 
Edo
I know you think you understand what you thought I said, but I'm not sure
you realize that what you heard is not what I meant (prob. Alan Greenspan)
:wq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190904/bd471acb/attachment.html>

From doenges at mvtec.com  Wed Sep  4 06:22:56 2019
From: doenges at mvtec.com (Eric Doenges)
Date: Wed, 4 Sep 2019 12:22:56 +0200
Subject: [CMake] external project CONFIGURE_COMMAND adds quotation to
 arguments
In-Reply-To: <CAJZDnTj=m8NoDYk=XpnokFv6OtCGc5EydLi2zW4+bBsqTzEi9g@mail.gmail.com>
References: <CAJZDnTj=m8NoDYk=XpnokFv6OtCGc5EydLi2zW4+bBsqTzEi9g@mail.gmail.com>
Message-ID: <6a392e5a-a420-5cdf-7bfd-47413889072d@mvtec.com>

An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190904/c66e1570/attachment.html>

From i.ivanov at trassir.com  Wed Sep  4 06:49:05 2019
From: i.ivanov at trassir.com (Igor Ivanov)
Date: Wed, 4 Sep 2019 13:49:05 +0300
Subject: [CMake] Finding custom qmake path
In-Reply-To: <1bc0e260-e1e7-5730-ef63-05937ed648a1@numalliance.com>
References: <cf029bc9-6263-4dde-4904-fc759406f167@numalliance.com>
 <1bc0e260-e1e7-5730-ef63-05937ed648a1@numalliance.com>
Message-ID: <326555a5-8c48-fdfb-249b-0234c9c5e4cd@trassir.com>

I might be wrong, but I think you can simply use target names, like 
`add_custom_command(COMMAND Qt5::qmake --arg file1 file2)`.

On 03.09.2019 16:36, St?phane Ancelot wrote:
>
> I solved it using
>
> |get_target_property (QT_QMAKE_EXECUTABLE Qt5::qmake IMPORTED_LOCATION)|
>
> Le 03/09/2019 ? 15:05, St?phane Ancelot a ?crit?:
>>
>> Hi,
>>
>> Is there a way to find qmake path of a custom setup in order using it 
>> an add_custom_command
>>
>> my QT5 path is available in CMAKE_PREFIX_PATH.
>>
>>
>> Regards,,
>>
>> S.Ancelot
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190904/313bb236/attachment.html>

From edo.paskino at gmail.com  Wed Sep  4 07:02:06 2019
From: edo.paskino at gmail.com (Edoardo Pasca)
Date: Wed, 4 Sep 2019 12:02:06 +0100
Subject: [CMake] external project CONFIGURE_COMMAND adds quotation to
 arguments
In-Reply-To: <6a392e5a-a420-5cdf-7bfd-47413889072d@mvtec.com>
References: <CAJZDnTj=m8NoDYk=XpnokFv6OtCGc5EydLi2zW4+bBsqTzEi9g@mail.gmail.com>
 <6a392e5a-a420-5cdf-7bfd-47413889072d@mvtec.com>
Message-ID: <CAJZDnTgWzA_Qtk+bUT2z+8zG6Oom-37o72E_TGKyru20v4KyYQ@mail.gmail.com>

Brilliant!

your suggestion has worked!

Thank you so much

Edo

On Wed, Sep 4, 2019 at 11:23 AM Eric Doenges <doenges at mvtec.com> wrote:

> On 04.09.2019 11:55, Edoardo Pasca wrote:
>
> Dear all,
>
> I'm using ExternalProjectAdd to build an external package.
>
> On the CONFIGURE_COMMAND I have to pass some variables to the configure
> script in this form:
>
> configure CPPFLAGS="-I/dir/include -L/dir/lib"
>
> To do this I use
>
> CONFIGURE_COMMAND ${CMAKE_COMMAND} -E env ${CMAKE_BINARY_DIR}/configure
> CPPFLAGS="-I/dir/include -L/dir/lib"
>
> However, when cmake issues that command (you can see that with make
> VERBOSE=1) it wraps the CPPFLAGS parameters with quotation marks (as below)
> and the configure script fails
>
> configure "CPPFLAGS=\"-I/dir/include -L/dir/lib\""
>
> Below you can find a minimal CMakeLists.txt to test this.
>
> I'd appreciate any help on how I'd remove those quotation marks.
>
> Thanks
>
> Edo
>
>
> What I do is let CMake handle this itself by defining a (list) variable
> for the configure command:
>
> set(cmd "${CMAKE_BINARY_DIR}/configure")
> list(APPEND cmd "CPPFLAGS=-I/dir/include -L/dir/lib")
> ExternalProject_Add(...
>   CONFIGURE_COMMAND ${CMAKE_COMMAND} -E env ${cmd}
>   ...)
>
> Since cmd is a list, CMake knows that the -L/dir/lib belongs to the
> CPPFLAGS=-I/dir/include part, and puts double quotes around the entire
> thing, e.g. the actual command line will look something like this:
>
> <xxx>/configure "CPPFLAG=-Idir/include -L/dir/lib"
> This works with GNU autoconf. I've found that in general, dealing with
> quoting in ExternalProject_Add is a gigantic pain, so if the method above
> is not sufficient, I use configure_file or file(WRITE) to generate a shell
> script (Linux) or batch file (Windows) with the correct parameters and call
> that instead.
>
> With kind regards,
> Eric D?nges
>
> *Dr. Eric D?nges *
> Senior Software Engineer
>
> MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
> doenges at mvtec.com | Tel: +49 89 457 695-0 | www.mvtec.com
>
>  Sign up <http://www.mvtec.com/newsletter> for our MVTec Newsletter!
>
> Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
> Amtsgericht M?nchen HRB 114695
>
>
> [image: MVTec Software GmbH Logo]
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Edo
I know you think you understand what you thought I said, but I'm not sure
you realize that what you heard is not what I meant (prob. Alan Greenspan)
:wq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190904/43a151d6/attachment-0001.html>

From robert.maynard at kitware.com  Wed Sep  4 11:50:00 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 4 Sep 2019 11:50:00 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.15.3 available for download
Message-ID: <CAFzjYVpmzw-Tw9e5g_50VpSSLmtWxYH1YviRi5o=h5a+5enC=g@mail.gmail.com>

We are pleased to announce that CMake 3.15.3 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-------------------------------------------------------------------------
Changes in 3.15.3 since 3.15.2:

Brad King (13):
  Flang: Implement MSVC runtime library abstraction
  CTest: Fix --show-only=json-v1 output with REQUIRED_FILES property
  cmGlobalGenerator: Fix CheckCompilerIdCompatibility local var lifetime
  cmAffinity: Add include for CPU_ZERO on Alpine Linux
  find_path: Fix crash on empty old-style list of names
  fileapi: Fix codemodel v2 target file name for CMP0037 OLD behavior
  FindBoost: Simplify conditional block for last known version
  FindBoost: Remove incorrect 1.70 timer dependency
  FindBoost: Unwrap compatibility INTERFACE targets for legacy variables
  FindBoost: Add support for Boost 1.71
  FindBoost: Clarify role of legacy variables in warning message
  FindBoost: Tolerate future Boost INTERFACE libraries
  CMake 3.15.3

Chuck Atkins (1):
  CrayPrgEnv: Change default linking mode based on PE version

M Furkan USLU (1):
  ccmake: handle cache entries with empty STRINGS property

Marvin Schmidt (1):
  libarchive: We now require at least version 3.3.3

Robert Maynard (1):
  FindMPI: Restore MPI_<LANG>_COMPILE_FLAGS and MPI_<LANG>_COMPILE_OPTIONS

Sebastian Holtermann (3):
  Ninja: Add support for ADDITIONAL_CLEAN_FILES in custom targets
  Tests: Extend MakeClean test to test various target types
  Autogen: Fix AUTOUIC segfault, when file includes colliding ui_*.h file

From christopher.dawes at eftlab.com  Wed Sep  4 12:22:56 2019
From: christopher.dawes at eftlab.com (Christopher Dawes)
Date: Wed, 4 Sep 2019 16:22:56 +0000
Subject: [CMake] The connection to cmake-server was terminated unexpectedly
 [cms-client] cmake-server exited with status null (SIGSEGV)
Message-ID: <4204717A-1DB2-4ACB-9A73-142D68D1D129@eftlab.com>

Hi there, we are experiencing a crash when working with VSCode on Ubuntu:

Brief Issue Summary

When starting up VSCode using the CMake extension i get this error on all my projects, the application terminates pretty quickly. What?s happening is cmake server is spawned and then crashes; i?m afraid i?m uncertain what commands are exchanged. I logged the issue against the cmake extension here https://github.com/microsoft/vscode-cmake-tools/issues/752 however it looks like the issue is with cmake rather than the way it?s being used.

Platform and Versions

  *   Operating System: Ubuntu 18.04
  *   CMake Version: 3.10.2
  *   VSCode Version: 1.37.1
  *   CMake Tools Extension Version: 1.13
  *   Compiler/Toolchain: GCC 7.4.0-1ubuntu1~18.04.1 with Ninja

Other Notes/Information

I've run with debug symbols however it's too big (33MB) to attach here, see

https://www.dropbox.com/s/cl7z4cxd5oyuvbr/with_symbols.txt?dl=0

Here's a small excerpt:

Thread 1 (Thread 0x7fce40c3a780 (LWP 28685)):
#0  std::__cxx11::basic_string, std::allocator >::_M_length (this=, __length=) at /usr/include/c++/7/bits/basic_string.h:172
No locals.
#1  std::__cxx11::basic_string, std::allocator >::_M_set_length (__n=, this=) at /usr/include/c++/7/bits/basic_string.h:205
No locals.
#2  std::__cxx11::basic_string, std::allocator >::basic_string (this=0x7ffdee7d5e40) at /usr/include/c++/7/bits/basic_string.h:423
No locals.
#3  cmsys::SystemTools::FileIsDirectory (inName=...) at ./Source/kwsys/SystemTools.cxx:2865
        length =
        name =
        local_buffer =
        string_buffer =
        last =
        fs =
#4  0x000055d2c7efa231 in cmListFile::ParseFile (this=this at entry=0x7ffdee7d7010, filename=0x55d2ca803700 "/usr/local/bp/share/cmake/FindLibXml2.cmake", messenger=0x55d2c8da6110, lfbt=...) at ./Source/cmListFileCache.cxx:139
        parseError =
#5  0x000055d2c7ca8c63 in cmMakefile::ReadDependentFile (this=0x55d2c8e139a0, filename=, noPolicyScope=noPolicyScope at entry=false) at ./Source/cmMakefile.cxx:444
        filenametoread = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803700 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000\v\000\000\000\000\000\000", _M_allocated_capacity = 45}}
        incScope = {Makefile = 0x55d2c8e139a0, NoPolicyScope = false, CheckCMP0011 = false, ReportError = true}
        listFile = {Functions = { >> = {_M_impl = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_start = 0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}}, }}
#6  0x000055d2c7d8e3bb in cmIncludeCommand::InitialPass (this=0x55d2ca8034c0, args=...) at ./Source/cmIncludeCommand.cxx:123
        readit =
        optional =
        noPolicyScope =
        fname = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803640 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000ml2\000\000\000\000", _M_allocated_capacity = 43}}
        resultVarName = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d7120 ""}, _M_string_length = 0, {_M_local_buf = "\000\000\000\000[\000\000\000Pc\357\310\322U\000", _M_allocated_capacity = 390842023936}}
        fname_abs = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803560 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000`5\200\312\322U\000", _M_allocated_capacity = 45}}
        gg = 0x55d2c8df16a0
        listFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803680 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-", '\000' , _M_allocated_capacity = 45}}
#7  0x000055d2c7d2709c in cmCommand::InvokeInitialPass (this=0x55d2ca8034c0, args=..., status=...) at ./Source/cmCommand.cxx:19
        expandedArguments = {, std::allocator >, std::allocator, std::allocator > > >> = {_M_impl = {, std::allocator > >> = {<__gnu_cxx::new_allocator, std::allocator > >> = {}, }, _M_start = 0x55d2ca8013a0, _M_finish = 0x55d2ca8013c0, _M_end_of_storage = 0x55d2ca8013c0}}, }
#8  0x000055d2c7ca7326 in cmMakefile::ExecuteCommand (this=this at entry=0x55d2c8e139a0, lff=..., status=...) at ./Source/cmMakefile.cxx:277
        invokeSucceeded =
        hadNestedError =
        pcmd = {_M_t = {_M_t = { >> = { >> = {, true>> = {> = {}, }, }, > = {_M_head_impl = 0x55d2ca8034c0}, }, }}}
        proto =
        result = true
        name = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d7400 "include"}, _M_string_length = 7, {_M_local_buf = "include\000p\205\336\310\322U\000", _M_allocated_capacity = 28539428140183145}}
        stack_manager = {Makefile = 0x55d2c8e139a0}
#9  0x000055d2c7ca79cd in cmMakefile::ReadListFile (this=this at entry=0x55d2c8e139a0, listFile=..., filenametoread=...) at ./Source/cmMakefile.cxx:529
        status = {ReturnInvoked = false, BreakInvoked = false, ContinueInvoked = false, NestedError = false}
        i = 2
        currentParentFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca8021d0 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000?\336\310\322U\000", _M_allocated_capacity = 43}}
        currentFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803440 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000\020a\332\310\322U\000", _M_allocated_capacity = 43}}
        numberFunctions =
#10 0x000055d2c7ca8c79 in cmMakefile::ReadDependentFile (this=0x55d2c8e139a0, filename=, noPolicyScope=noPolicyScope at entry=false) at ./Source/cmMakefile.cxx:449
        filenametoread = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca8014c0 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000\v\000\000\000\000\000\000", _M_allocated_capacity = 45}}
        incScope = {Makefile = 0x55d2c8e139a0, NoPolicyScope = false, CheckCMP0011 = false, ReportError = true}
        listFile = {Functions = { >> = {_M_impl = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_start = 0x55d2ca801bd0, _M_finish = 0x55d2ca801f50, _M_end_of_storage = 0x55d2ca801fd0}}, }}
#11 0x000055d2c7d8e3bb in cmIncludeCommand::InitialPass (this=0x55d2ca801280, args=...) at ./Source/cmIncludeCommand.cxx:123
        readit =
        optional =
        noPolicyScope =
        fname = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca801400 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000ml2\000\000\000\000", _M_allocated_capacity = 43}}
        resultVarName = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d7710 ""}, _M_string_length = 0, {_M_local_buf = "\000\000\000\000[\000\000\000Pc\357\310\322U\000", _M_allocated_capacity = 390842023936}}
        fname_abs = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca801320 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000 \023\200\312\322U\000", _M_allocated_capacity = 45}}
        gg = 0x55d2c8df16a0
        listFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca801440 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-", '\000' , _M_allocated_capacity = 45}}
#12 0x000055d2c7d2709c in cmCommand::InvokeInitialPass (this=0x55d2ca801280, args=..., status=...) at ./Source/cmCommand.cxx:19
        expandedArguments = {, std::allocator >, std::allocator, std::allocator > > >> = {_M_impl = {, std::allocator > >> = {<__gnu_cxx::new_allocator, std::allocator > >> = {}, }, _M_start = 0x55d2ca8024e0, _M_finish = 0x55d2ca802500, _M_end_of_storage = 0x55d2ca802500}}, }
#13 0x000055d2c7ca7326 in cmMakefile::ExecuteCommand (this=this at entry=0x55d2c8e139a0, lff=..., status=...) at ./Source/cmMakefile.cxx:277
        invokeSucceeded =
        hadNestedError =
        pcmd = {_M_t = {_M_t = { >> = { >> = {, true>> = {> = {}, }, }, > = {_M_head_impl = 0x55d2ca801280}, }, }}}
        proto =
        result = true
        name = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d79f0 "include"}, _M_string_length = 7, {_M_local_buf = "include\000p\205\336\310\322U\000", _M_allocated_capacity = 28539428140183145}}
        stack_manager = {Makefile = 0x55d2c8e139a0}
#14 0x000055d2c7ca79cd in cmMakefile::ReadListFile (this=this at entry=0x55d2c8e139a0, listFile=..., filenametoread=...) at ./Source/cmMakefile.cxx:529
        status = {ReturnInvoked = false, BreakInvoked = false, ContinueInvoked = false, NestedError = false}
        i = 2
        currentParentFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca802ff0 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000?\336\310\322U\000", _M_allocated_capacity = 43}}
        currentFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca801200 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000\020a\332\310\322U\000", _M_allocated_capacity = 43}}
        numberFunctions =
#15 0x000055d2c7ca8c79 in cmMakefile::ReadDependentFile (this=0x55d2c8e139a0, filename=, noPolicyScope=noPolicyScope at entry=false) at ./Source/cmMakefile.cxx:449
        filenametoread = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca802600 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000\v\000\000\000\000\000\000", _M_allocated_capacity = 45}}
        incScope = {Makefile = 0x55d2c8e139a0, NoPolicyScope = false, CheckCMP0011 = false, ReportError = true}
        listFile = {Functions = { >> = {_M_impl = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_start = 0x55d2ca807450, _M_finish = 0x55d2ca8077d0, _M_end_of_storage = 0x55d2ca807850}}, }}
#16 0x000055d2c7d8e3bb in cmIncludeCommand::InitialPass (this=0x55d2ca8023c0, args=...) at ./Source/cmIncludeCommand.cxx:123
        readit =
        optional =
        noPolicyScope =
        fname = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca802540 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000ml2\000\000\000\000", _M_allocated_capacity = 43}}
        resultVarName = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d7d00 ""}, _M_string_length = 0, {_M_local_buf = "\000\000\000\000[\000\000\000Pc\357\310\322U\000", _M_allocated_capacity = 390842023936}}
        fname_abs = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca802460 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000`$\200\312\322U\000", _M_allocated_capacity = 45}}
        gg = 0x55d2c8df16a0
        listFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca802580 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-", '\000' , _M_allocated_capacity = 45}}
#17 0x000055d2c7d2709c in cmCommand::InvokeInitialPass (this=0x55d2ca8023c0, args=..., status=...) at ./Source/cmCommand.cxx:19
        expandedArguments = {, std::allocator >, std::allocator, std::allocator > > >> = {_M_impl = {, std::allocator > >> = {<__gnu_cxx::new_allocator, std::allocator > >> = {}, }, _M_start = 0x55d2ca8002e0, _M_finish = 0x55d2ca800300, _M_end_of_storage = 0x55d2ca800300}}, }
#18 0x000055d2c7ca7326 in cmMakefile::ExecuteCommand (this=this at entry=0x55d2c8e139a0, lff=..., status=...) at ./Source/cmMakefile.cxx:277
        invokeSucceeded =
        hadNestedError =
        pcmd = {_M_t = {_M_t = { >> = { >> = {, true>> = {> = {}, }, }, > = {_M_head_impl = 0x55d2ca8023c0}, }, }}}
        proto =
        result = true
        name = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d7fe0 "include"}, _M_string_length = 7, {_M_local_buf = "include\000p\205\336\310\322U\000", _M_allocated_capacity = 28539428140183145}}
        stack_manager = {Makefile = 0x55d2c8e139a0}
#19 0x000055d2c7ca79cd in cmMakefile::ReadListFile (this=this at entry=0x55d2c8e139a0, listFile=..., filenametoread=...) at ./Source/cmMakefile.cxx:529
        status = {ReturnInvoked = false, BreakInvoked = false, ContinueInvoked = false, NestedError = false}
        i = 2
        currentParentFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca802300 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000?\336\310\322U\000", _M_allocated_capacity = 43}}
        currentFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca802340 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000\020a\332\310\322U\000", _M_allocated_capacity = 43}}
        numberFunctions =
#20 0x000055d2c7ca8c79 in cmMakefile::ReadDependentFile (this=0x55d2c8e139a0, filename=, noPolicyScope=noPolicyScope at entry=false) at ./Source/cmMakefile.cxx:449
        filenametoread = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca800400 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000\v\000\000\000\000\000\000", _M_allocated_capacity = 45}}
        incScope = {Makefile = 0x55d2c8e139a0, NoPolicyScope = false, CheckCMP0011 = false, ReportError = true}
        listFile = {Functions = { >> = {_M_impl = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_start = 0x55d2ca800b10, _M_finish = 0x55d2ca800e90, _M_end_of_storage = 0x55d2ca800f10}}, }}
#21 0x000055d2c7d8e3bb in cmIncludeCommand::InitialPass (this=0x55d2ca8001c0, args=...) at ./Source/cmIncludeCommand.cxx:123
        readit =
        optional =
        noPolicyScope =
        fname = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca800340 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000ml2\000\000\000\000", _M_allocated_capacity = 43}}
        resultVarName = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d82f0 ""}, _M_string_length = 0, {_M_local_buf = "\000\000\000\000[\000\000\000Pc\357\310\322U\000", _M_allocated_capacity = 390842023936}}
        fname_abs = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca800260 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000`\002\200\312\322U\000", _M_allocated_capacity = 45}}
        gg = 0x55d2c8df16a0
        listFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca800380 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-", '\000' , _M_allocated_capacity = 45}}
#22 0x000055d2c7d2709c in cmCommand::InvokeInitialPass (this=0x55d2ca8001c0, args=..., status=...) at ./Source/cmCommand.cxx:19
        expandedArguments = {, std::allocator >, std::allocator

Any assistance would be much appreciated. More than happy to do a remote debug session if that would help.

Thanks and Regards


Christopher Dawes
Principal Architect, EFTLab

M: +44 (0)7899 842 759
E: christopher.dawes at eftlab.com<mailto:christopher.dawes at eftlab.com>
A: 109 Brighton Road, Sandgate, QLD 4017

IMPORTANT NOTICE
This message contains confidential information and is intended only for the addressee(s). E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. EFTlab Pty Ltd cannot accept liability for any errors or omissions in the contents of this message, which may arise as a result of e-mail transmission. Please note that EFTlab Pty Ltd may monitor, analyse and archive email traffic, data and the content of email for the purposes of security, legal compliance and staff training. If you have received this email in error please notify us at support at eftlab.com.au<mailto:support at eftlab.com.au>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190904/1aa05d57/attachment-0001.html>

From fdk17 at ftml.net  Wed Sep  4 14:12:48 2019
From: fdk17 at ftml.net (fdk17)
Date: Wed, 04 Sep 2019 14:12:48 -0400
Subject: [CMake] 
 =?utf-8?q?The_connection_to_cmake-server_was_terminated_?=
 =?utf-8?q?unexpectedly_=5Bcms-client=5D_cmake-server_exited_with_status_n?=
 =?utf-8?q?ull_=28SIGSEGV=29?=
In-Reply-To: <4204717A-1DB2-4ACB-9A73-142D68D1D129@eftlab.com>
References: <4204717A-1DB2-4ACB-9A73-142D68D1D129@eftlab.com>
Message-ID: <ecf37d7b-c13d-4fc8-8426-3c7a6d2301d2@www.fastmail.com>

https://github.com/microsoft/vscode-cmake-tools/issues/752 states that it ran out of stack and the log shows what looks like to be involved with a recursive loop in some CMakeLists.txt. A call depth of 27491 seems a bit excessive.

After the second call to FindPackage it just seems to be doing the same thing over and over again.
I'd think a newer version of CMake would complain about too much recursion in the project files.

Does the project work on the command line without involving VSCode?
It could be something different in the environment if it works on the command line but not as server instance in VSCode.

--
F

On Wed, Sep 4, 2019, at 12:22 PM, Christopher Dawes wrote:
> Hi there, we are experiencing a crash when working with VSCode on Ubuntu:
> 
> Brief Issue Summary

> When starting up VSCode using the CMake extension i get this error on all my projects, the application terminates pretty quickly. What?s happening is cmake server is spawned and then crashes; i?m afraid i?m uncertain what commands are exchanged. I logged the issue against the cmake extension here  https://github.com/microsoft/vscode-cmake-tools/issues/752 however it looks like the issue is with cmake rather than the way it?s being used.

> Platform and Versions

>  * Operating System: Ubuntu 18.04
>  * CMake Version: 3.10.2
>  * VSCode Version: 1.37.1
>  * CMake Tools Extension Version: 1.13
>  * Compiler/Toolchain: GCC 7.4.0-1ubuntu1~18.04.1 with Ninja
> Other Notes/Information

> I've run with debug symbols however it's too big (33MB) to attach here, see

> https://www.dropbox.com/s/cl7z4cxd5oyuvbr/with_symbols.txt?dl=0

> Here's a small excerpt:
> Thread 1 (Thread 0x7fce40c3a780 (LWP 28685)):
#0  std::__cxx11::basic_string, std::allocator >::_M_length (this=, __length=) at /usr/include/c++/7/bits/basic_string.h:172
No locals.
#1  std::__cxx11::basic_string, std::allocator >::_M_set_length (__n=, this=) at /usr/include/c++/7/bits/basic_string.h:205
No locals.
#2  std::__cxx11::basic_string, std::allocator >::basic_string (this=0x7ffdee7d5e40) at /usr/include/c++/7/bits/basic_string.h:423
No locals.
#3  cmsys::SystemTools::FileIsDirectory (inName=...) at ./Source/kwsys/SystemTools.cxx:2865
        length = 
        name = 
        local_buffer = 
        string_buffer = 
        last = 
        fs = 
#4  0x000055d2c7efa231 in cmListFile::ParseFile (this=this at entry=0x7ffdee7d7010, filename=0x55d2ca803700 "/usr/local/bp/share/cmake/FindLibXml2.cmake", messenger=0x55d2c8da6110, lfbt=...) at ./Source/cmListFileCache.cxx:139
        parseError = 
#5  0x000055d2c7ca8c63 in cmMakefile::ReadDependentFile (this=0x55d2c8e139a0, filename=, noPolicyScope=noPolicyScope at entry=false) at ./Source/cmMakefile.cxx:444
        filenametoread = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803700 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000\v\000\000\000\000\000\000", _M_allocated_capacity = 45}}
        incScope = {Makefile = 0x55d2c8e139a0, NoPolicyScope = false, CheckCMP0011 = false, ReportError = true}
        listFile = {Functions = { >> = {_M_impl = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_start = 0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}}, }}
#6  0x000055d2c7d8e3bb in cmIncludeCommand::InitialPass (this=0x55d2ca8034c0, args=...) at ./Source/cmIncludeCommand.cxx:123
        readit = 
        optional = 
        noPolicyScope = 
        fname = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803640 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000ml2\000\000\000\000", _M_allocated_capacity = 43}}
        resultVarName = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d7120 ""}, _M_string_length = 0, {_M_local_buf = "\000\000\000\000[\000\000\000Pc\357\310\322U\000", _M_allocated_capacity = 390842023936}}
        fname_abs = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803560 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000`5\200\312\322U\000", _M_allocated_capacity = 45}}
        gg = 0x55d2c8df16a0
        listFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803680 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-", '\000' , _M_allocated_capacity = 45}}
#7  0x000055d2c7d2709c in cmCommand::InvokeInitialPass (this=0x55d2ca8034c0, args=..., status=...) at ./Source/cmCommand.cxx:19
        expandedArguments = {, std::allocator >, std::allocator, std::allocator > > >> = {_M_impl = {, std::allocator > >> = {<__gnu_cxx::new_allocator, std::allocator > >> = {}, }, _M_start = 0x55d2ca8013a0, _M_finish = 0x55d2ca8013c0, _M_end_of_storage = 0x55d2ca8013c0}}, }
#8  0x000055d2c7ca7326 in cmMakefile::ExecuteCommand (this=this at entry=0x55d2c8e139a0, lff=..., status=...) at ./Source/cmMakefile.cxx:277
        invokeSucceeded = 
        hadNestedError = 
        pcmd = {_M_t = {_M_t = { >> = { >> = {, true>> = {> = {}, }, }, > = {_M_head_impl = 0x55d2ca8034c0}, }, }}}
        proto = 
        result = true
        name = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d7400 "include"}, _M_string_length = 7, {_M_local_buf = "include\000p\205\336\310\322U\000", _M_allocated_capacity = 28539428140183145}}
        stack_manager = {Makefile = 0x55d2c8e139a0}
#9  0x000055d2c7ca79cd in cmMakefile::ReadListFile (this=this at entry=0x55d2c8e139a0, listFile=..., filenametoread=...) at ./Source/cmMakefile.cxx:529
        status = {ReturnInvoked = false, BreakInvoked = false, ContinueInvoked = false, NestedError = false}
        i = 2
        currentParentFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca8021d0 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000?\336\310\322U\000", _M_allocated_capacity = 43}}
        currentFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803440 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000\020a\332\310\322U\000", _M_allocated_capacity = 43}}
        numberFunctions = 
#10 0x000055d2c7ca8c79 in cmMakefile::ReadDependentFile (this=0x55d2c8e139a0, filename=, noPolicyScope=noPolicyScope at entry=false) at ./Source/cmMakefile.cxx:449
        filenametoread = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca8014c0 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000\v\000\000\000\000\000\000", _M_allocated_capacity = 45}}
        incScope = {Makefile = 0x55d2c8e139a0, NoPolicyScope = false, CheckCMP0011 = false, ReportError = true}
        listFile = {Functions = { >> = {_M_impl = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_start = 0x55d2ca801bd0, _M_finish = 0x55d2ca801f50, _M_end_of_storage = 0x55d2ca801fd0}}, }}
#11 0x000055d2c7d8e3bb in cmIncludeCommand::InitialPass (this=0x55d2ca801280, args=...) at ./Source/cmIncludeCommand.cxx:123
        readit = 
        optional = 
        noPolicyScope = 
        fname = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca801400 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000ml2\000\000\000\000", _M_allocated_capacity = 43}}
        resultVarName = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d7710 ""}, _M_string_length = 0, {_M_local_buf = "\000\000\000\000[\000\000\000Pc\357\310\322U\000", _M_allocated_capacity = 390842023936}}
        fname_abs = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca801320 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000 \023\200\312\322U\000", _M_allocated_capacity = 45}}
        gg = 0x55d2c8df16a0
        listFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca801440 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-", '\000' , _M_allocated_capacity = 45}}
#12 0x000055d2c7d2709c in cmCommand::InvokeInitialPass (this=0x55d2ca801280, args=..., status=...) at ./Source/cmCommand.cxx:19
        expandedArguments = {, std::allocator >, std::allocator, std::allocator > > >> = {_M_impl = {, std::allocator > >> = {<__gnu_cxx::new_allocator, std::allocator > >> = {}, }, _M_start = 0x55d2ca8024e0, _M_finish = 0x55d2ca802500, _M_end_of_storage = 0x55d2ca802500}}, }
#13 0x000055d2c7ca7326 in cmMakefile::ExecuteCommand (this=this at entry=0x55d2c8e139a0, lff=..., status=...) at ./Source/cmMakefile.cxx:277
        invokeSucceeded = 
        hadNestedError = 
        pcmd = {_M_t = {_M_t = { >> = { >> = {, true>> = {> = {}, }, }, > = {_M_head_impl = 0x55d2ca801280}, }, }}}
        proto = 
        result = true
        name = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d79f0 "include"}, _M_string_length = 7, {_M_local_buf = "include\000p\205\336\310\322U\000", _M_allocated_capacity = 28539428140183145}}
        stack_manager = {Makefile = 0x55d2c8e139a0}
#14 0x000055d2c7ca79cd in cmMakefile::ReadListFile (this=this at entry=0x55d2c8e139a0, listFile=..., filenametoread=...) at ./Source/cmMakefile.cxx:529
        status = {ReturnInvoked = false, BreakInvoked = false, ContinueInvoked = false, NestedError = false}
        i = 2
        currentParentFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca802ff0 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000?\336\310\322U\000", _M_allocated_capacity = 43}}
        currentFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca801200 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000\020a\332\310\322U\000", _M_allocated_capacity = 43}}
        numberFunctions = 
#15 0x000055d2c7ca8c79 in cmMakefile::ReadDependentFile (this=0x55d2c8e139a0, filename=, noPolicyScope=noPolicyScope at entry=false) at ./Source/cmMakefile.cxx:449
        filenametoread = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca802600 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000\v\000\000\000\000\000\000", _M_allocated_capacity = 45}}
        incScope = {Makefile = 0x55d2c8e139a0, NoPolicyScope = false, CheckCMP0011 = false, ReportError = true}
        listFile = {Functions = { >> = {_M_impl = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_start = 0x55d2ca807450, _M_finish = 0x55d2ca8077d0, _M_end_of_storage = 0x55d2ca807850}}, }}
#16 0x000055d2c7d8e3bb in cmIncludeCommand::InitialPass (this=0x55d2ca8023c0, args=...) at ./Source/cmIncludeCommand.cxx:123
        readit = 
        optional = 
        noPolicyScope = 
        fname = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca802540 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000ml2\000\000\000\000", _M_allocated_capacity = 43}}
        resultVarName = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d7d00 ""}, _M_string_length = 0, {_M_local_buf = "\000\000\000\000[\000\000\000Pc\357\310\322U\000", _M_allocated_capacity = 390842023936}}
        fname_abs = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca802460 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000`$\200\312\322U\000", _M_allocated_capacity = 45}}
        gg = 0x55d2c8df16a0
        listFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca802580 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-", '\000' , _M_allocated_capacity = 45}}
#17 0x000055d2c7d2709c in cmCommand::InvokeInitialPass (this=0x55d2ca8023c0, args=..., status=...) at ./Source/cmCommand.cxx:19
        expandedArguments = {, std::allocator >, std::allocator, std::allocator > > >> = {_M_impl = {, std::allocator > >> = {<__gnu_cxx::new_allocator, std::allocator > >> = {}, }, _M_start = 0x55d2ca8002e0, _M_finish = 0x55d2ca800300, _M_end_of_storage = 0x55d2ca800300}}, }
#18 0x000055d2c7ca7326 in cmMakefile::ExecuteCommand (this=this at entry=0x55d2c8e139a0, lff=..., status=...) at ./Source/cmMakefile.cxx:277
        invokeSucceeded = 
        hadNestedError = 
        pcmd = {_M_t = {_M_t = { >> = { >> = {, true>> = {> = {}, }, }, > = {_M_head_impl = 0x55d2ca8023c0}, }, }}}
        proto = 
        result = true
        name = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d7fe0 "include"}, _M_string_length = 7, {_M_local_buf = "include\000p\205\336\310\322U\000", _M_allocated_capacity = 28539428140183145}}
        stack_manager = {Makefile = 0x55d2c8e139a0}
#19 0x000055d2c7ca79cd in cmMakefile::ReadListFile (this=this at entry=0x55d2c8e139a0, listFile=..., filenametoread=...) at ./Source/cmMakefile.cxx:529
        status = {ReturnInvoked = false, BreakInvoked = false, ContinueInvoked = false, NestedError = false}
        i = 2
        currentParentFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca802300 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000?\336\310\322U\000", _M_allocated_capacity = 43}}
        currentFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca802340 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000\020a\332\310\322U\000", _M_allocated_capacity = 43}}
        numberFunctions = 
#20 0x000055d2c7ca8c79 in cmMakefile::ReadDependentFile (this=0x55d2c8e139a0, filename=, noPolicyScope=noPolicyScope at entry=false) at ./Source/cmMakefile.cxx:449
        filenametoread = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca800400 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000\v\000\000\000\000\000\000", _M_allocated_capacity = 45}}
        incScope = {Makefile = 0x55d2c8e139a0, NoPolicyScope = false, CheckCMP0011 = false, ReportError = true}
        listFile = {Functions = { >> = {_M_impl = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_start = 0x55d2ca800b10, _M_finish = 0x55d2ca800e90, _M_end_of_storage = 0x55d2ca800f10}}, }}
#21 0x000055d2c7d8e3bb in cmIncludeCommand::InitialPass (this=0x55d2ca8001c0, args=...) at ./Source/cmIncludeCommand.cxx:123
        readit = 
        optional = 
        noPolicyScope = 
        fname = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca800340 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "+\000\000\000\000\000\000\000ml2\000\000\000\000", _M_allocated_capacity = 43}}
        resultVarName = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d82f0 ""}, _M_string_length = 0, {_M_local_buf = "\000\000\000\000[\000\000\000Pc\357\310\322U\000", _M_allocated_capacity = 390842023936}}
        fname_abs = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca800260 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-\000\000\000\000\000\000\000`\002\200\312\322U\000", _M_allocated_capacity = 45}}
        gg = 0x55d2c8df16a0
        listFile = {static npos = 18446744073709551615, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca800380 "/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, {_M_local_buf = "-", '\000' , _M_allocated_capacity = 45}}
#22 0x000055d2c7d2709c in cmCommand::InvokeInitialPass (this=0x55d2ca8001c0, args=..., status=...) at ./Source/cmCommand.cxx:19
        expandedArguments = {, std::allocator >, std::allocator
> 
> Any assistance would be much appreciated. More than happy to do a remote debug session if that would help.
> 
> Thanks and Regards 
> 
> 
> *Christopher Dawes*
> *Principal Architect, EFTLab** *
> 
> *M:* +44 (0)7899 842 759
> *E:* christopher.dawes at eftlab.com
> *A:* 109 Brighton Road, Sandgate, QLD 4017
> 
> *IMPORTANT NOTICE* 
> This message contains confidential information and is intended only for the addressee(s). E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. EFTlab Pty Ltd cannot accept liability for any errors or omissions in the contents of this message, which may arise as a result of e-mail transmission. Please note that EFTlab Pty Ltd may monitor, analyse and archive email traffic, data and the content of email for the purposes of security, legal compliance and staff training. If you have received this email in error please notify us at support at eftlab.com.au. 
> 
> -- 
> 
> 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 services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190904/0c40d2dd/attachment-0001.html>

From kyle.edwards at kitware.com  Wed Sep  4 14:39:14 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Wed, 04 Sep 2019 14:39:14 -0400
Subject: [CMake] The connection to cmake-server was terminated
 unexpectedly [cms-client] cmake-server exited with status null (SIGSEGV)
In-Reply-To: <ecf37d7b-c13d-4fc8-8426-3c7a6d2301d2@www.fastmail.com>
References: <4204717A-1DB2-4ACB-9A73-142D68D1D129@eftlab.com>
 <ecf37d7b-c13d-4fc8-8426-3c7a6d2301d2@www.fastmail.com>
Message-ID: <1567622354.16243.1.camel@kitware.com>

On Wed, 2019-09-04 at 14:12 -0400, fdk17 wrote:
> https://github.com/microsoft/vscode-cmake-tools/issues/752 states
> that it ran out of stack and the log shows what looks like to be
> involved with a recursive loop in some CMakeLists.txt.? A call depth
> of 27491 seems a bit excessive.
> 
> After the second call to FindPackage it just seems to be doing the
> same thing over and over again.
> I'd think a newer version of CMake would complain about too much
> recursion in the project files.

Indeed, this was added in 3.14:

https://cmake.org/cmake/help/v3.14/variable/CMAKE_MAXIMUM_RECURSION_DEP
TH.html
Kyle

From christopher.dawes at eftlab.com  Wed Sep  4 17:56:36 2019
From: christopher.dawes at eftlab.com (Christopher Dawes)
Date: Wed, 4 Sep 2019 21:56:36 +0000
Subject: [CMake] The connection to cmake-server was terminated
 unexpectedly [cms-client] cmake-server exited with status null (SIGSEGV)
In-Reply-To: <1567622354.16243.1.camel@kitware.com>
References: <4204717A-1DB2-4ACB-9A73-142D68D1D129@eftlab.com>
 <ecf37d7b-c13d-4fc8-8426-3c7a6d2301d2@www.fastmail.com>
 <1567622354.16243.1.camel@kitware.com>
Message-ID: <5AA6DF4D-76BE-4C28-8B07-9D4CE6721DAD@eftlab.com>

Awesome thank you so much! So i?ve upgraded to 3.15.3 and it?s told me perfectly my issue. So I have an override script (FindLibXml2.cmake):

*************************** START CODE ***************************
# FindLibXml2.cmake
#
# A wrapper around CMake's FindLibXml2 which provides an imported target.

# Find LibXml2 using the built-in module
set(_cmake_module_path "${CMAKE_MODULE_PATH}")
set(CMAKE_MODULE_PATH)
include(FindLibXml2)
set(CMAKE_MODULE_PATH "${_cmake_module_path}")

if(LibXml2_FOUND AND NOT TARGET LibXml2::LibXml2)
  add_library(LibXml2::LibXml2 INTERFACE IMPORTED)
  set_target_properties(LibXml2::LibXml2 PROPERTIES
    INTERFACE_LINK_LIBRARIES "${LIBXML2_LIBRARIES}"
    INTERFACE_INCLUDE_DIRECTORIES "${LIBXML2_INCLUDE_DIR}")
else()
  #https://github.com/Homebrew/homebrew-core/issues/6186
  if(APPLE)
    get_target_property(id LibXml2::LibXml2 INTERFACE_INCLUDE_DIRECTORIES)
    list(REMOVE_ITEM id "/usr/include/libxml2")
    set_target_properties(LibXml2::LibXml2 PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${id}")
  endif()
endif()

*************************** END CODE ***************************

So the issue was:
  set(CMAKE_MODULE_PATH)

doesn?t work in cmake-server; also unset(CMAKE_MODULE_PATH) didn?t work either, when i do:

set(CMAKE_MODULE_PATH ?/nonexistent?)

it all comes good; for some reason i think unset isn?t quite happy on cmake-server.

Many thanks again for your quick response!

Christopher Dawes
Principal Architect, EFTLab

M: +44 (0)7899 842 759
E: christopher.dawes at eftlab.com<mailto:christopher.dawes at eftlab.com>
A: 109 Brighton Road, Sandgate, QLD 4017

IMPORTANT NOTICE
This message contains confidential information and is intended only for the addressee(s). E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. EFTlab Pty Ltd cannot accept liability for any errors or omissions in the contents of this message, which may arise as a result of e-mail transmission. Please note that EFTlab Pty Ltd may monitor, analyse and archive email traffic, data and the content of email for the purposes of security, legal compliance and staff training. If you have received this email in error please notify us at support at eftlab.com.au<mailto:support at eftlab.com.au>.

On 4 Sep 2019, at 19:39, Kyle Edwards via CMake <cmake at cmake.org<mailto:cmake at cmake.org>> wrote:

On Wed, 2019-09-04 at 14:12 -0400, fdk17 wrote:
https://github.com/microsoft/vscode-cmake-tools/issues/752 states
that it ran out of stack and the log shows what looks like to be
involved with a recursive loop in some CMakeLists.txt.  A call depth
of 27491 seems a bit excessive.

After the second call to FindPackage it just seems to be doing the
same thing over and over again.
I'd think a newer version of CMake would complain about too much
recursion in the project files.

Indeed, this was added in 3.14:

https://cmake.org/cmake/help/v3.14/variable/CMAKE_MAXIMUM_RECURSION_DEP
TH.html
Kyle
--

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 services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190904/10e70664/attachment-0001.html>

From craig.scott at crascit.com  Wed Sep  4 18:21:25 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Thu, 5 Sep 2019 08:21:25 +1000
Subject: [CMake] The connection to cmake-server was terminated
 unexpectedly [cms-client] cmake-server exited with status null (SIGSEGV)
In-Reply-To: <5AA6DF4D-76BE-4C28-8B07-9D4CE6721DAD@eftlab.com>
References: <4204717A-1DB2-4ACB-9A73-142D68D1D129@eftlab.com>
 <ecf37d7b-c13d-4fc8-8426-3c7a6d2301d2@www.fastmail.com>
 <1567622354.16243.1.camel@kitware.com>
 <5AA6DF4D-76BE-4C28-8B07-9D4CE6721DAD@eftlab.com>
Message-ID: <CA+dygYnFBBiS3dVgHbTpoH5pf0N_Gz60_YccFe6U0PFmP+Syjw@mail.gmail.com>

On Thu, Sep 5, 2019 at 7:56 AM Christopher Dawes <
christopher.dawes at eftlab.com> wrote:

> Awesome thank you so much! So i?ve upgraded to 3.15.3 and it?s told me
> perfectly my issue. So I have an override script (FindLibXml2.cmake):
>
> *************************** START CODE ***************************
> # FindLibXml2.cmake
> #
> # A wrapper around CMake's FindLibXml2 which provides an imported target.
>
> # Find LibXml2 using the built-in module
> set(_cmake_module_path "${CMAKE_MODULE_PATH}")
> set(CMAKE_MODULE_PATH)
> include(FindLibXml2)
> set(CMAKE_MODULE_PATH "${_cmake_module_path}")
>
> if(LibXml2_FOUND AND NOT TARGET LibXml2::LibXml2)
>   add_library(LibXml2::LibXml2 INTERFACE IMPORTED)
>   set_target_properties(LibXml2::LibXml2 PROPERTIES
>     INTERFACE_LINK_LIBRARIES "${LIBXML2_LIBRARIES}"
>     INTERFACE_INCLUDE_DIRECTORIES "${LIBXML2_INCLUDE_DIR}")
> else()
>   #https://github.com/Homebrew/homebrew-core/issues/6186
>   if(APPLE)
>     get_target_property(id LibXml2::LibXml2 INTERFACE_INCLUDE_DIRECTORIES)
>     list(REMOVE_ITEM id "/usr/include/libxml2")
>     set_target_properties(LibXml2::LibXml2 PROPERTIES
> INTERFACE_INCLUDE_DIRECTORIES "${id}")
>   endif()
> endif()
>
> *************************** END CODE ***************************
>
> So the issue was:
>   set(CMAKE_MODULE_PATH)
>
> doesn?t work in cmake-server; also unset(CMAKE_MODULE_PATH) didn?t work
> either, when i do:
>
> set(CMAKE_MODULE_PATH ?/nonexistent?)
>
> it all comes good; for some reason i think unset isn?t quite happy on
> cmake-server.
>

Check that you don't also have a CMAKE_MODULE_PATH cache variable as well.
If you unset the non-cache variable, it will effectively unmask the cache
variable of the same name.





> Many thanks again for your quick response!
>
> *Christopher Dawes*
> *Principal Architect, EFTLab*
>
> *M:* +44 (0)7899 842 759
> *E:* christopher.dawes at eftlab.com
> *A:* 109 Brighton Road, Sandgate, QLD 4017
>
> *IMPORTANT NOTICE*
> This message contains confidential information and is intended only for
> the addressee(s). E-mail transmission cannot be guaranteed to be secure or
> error-free as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses. EFTlab Pty Ltd cannot accept
> liability for any errors or omissions in the contents of this message,
> which may arise as a result of e-mail transmission. Please note that EFTlab
> Pty Ltd may monitor, analyse and archive email traffic, data and the
> content of email for the purposes of security, legal compliance and staff
> training. If you have received this email in error please notify us at
> support at eftlab.com.au.
>
> On 4 Sep 2019, at 19:39, Kyle Edwards via CMake <cmake at cmake.org> wrote:
>
> On Wed, 2019-09-04 at 14:12 -0400, fdk17 wrote:
>
> https://github.com/microsoft/vscode-cmake-tools/issues/752 states
> that it ran out of stack and the log shows what looks like to be
> involved with a recursive loop in some CMakeLists.txt.  A call depth
> of 27491 seems a bit excessive.
>
> After the second call to FindPackage it just seems to be doing the
> same thing over and over again.
> I'd think a newer version of CMake would complain about too much
> recursion in the project files.
>
>
> Indeed, this was added in 3.14:
>
> https://cmake.org/cmake/help/v3.14/variable/CMAKE_MAXIMUM_RECURSION_DEP
> TH.html
> Kyle
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
>
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190905/a3b5e6c4/attachment.html>

From kurt.sansom at cfdrc.com  Thu Sep  5 12:36:17 2019
From: kurt.sansom at cfdrc.com (Kurt R. Sansom)
Date: Thu, 5 Sep 2019 16:36:17 +0000
Subject: [CMake] fortran end of file error in object files
Message-ID: <5C66539BA5232D429828F4290A39BA7ED02089@Mail.cfdrc.com>

Dear all,
   I am working on some fortran code that links to c++, and have run into an issue where make doesn't like the generated object file. There is something weird going on either in the preprocessing or something weird with my machine. What is weird is that people with the same OS, compiler etc don't have this issue and it builds without a problem inside of docker on this machine. I also have compiled some fortran examples that have hardcoded gfortran calls and works fine. I tested this with a different fotran project (json fortran library) and the cmake gave the same error.

I tried with cmake latest release and the same problem occurs. Can someone point me in a better direction here. Compiling on ubuntu 18.04, gcc-7, gfortran.

~Kurt  Sansom


Errors look something like:

f951: Fatal Error: Reading module 'class_patch' at line 1368 column 66: Unexpected EOF
compilation terminated.
src/core/CMakeFiles/core.dir/build.make:470: recipe for target 'src/core/CMakeFiles/core.dir/class-vars/class_geom_printer.f90.o' failed
make[2]: *** [src/core/CMakeFiles/core.dir/class-vars/class_geom_printer.f90.o] Error 1
CMakeFiles/Makefile2:296: recipe for target 'src/core/CMakeFiles/core.dir/all' failed
make[1]: *** [src/core/CMakeFiles/core.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190905/f34c3ba4/attachment.html>

From jiapei at longervision.com  Sun Sep  8 05:19:29 2019
From: jiapei at longervision.com (Pei Jia)
Date: Sun, 8 Sep 2019 02:19:29 -0700
Subject: [CMake] Specify "NO multilib" for cross compilation ???
Message-ID: <9f461af7-2d51-628f-fe61-8e6019677b5e@longervision.com>


Hi, all:

I'm trying to cross compile a package with CMake. I strictly followed 
the documentation here: 
https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html

But, still obtained the following ERROR messages:



CMake Error at /usr/share/cmake-3.13/Modules/CMakeTestCCompiler.cmake:52 
(message):
The C compiler

"....../RPi/bin/arm-rpi-linux-gnueabihf-gcc"

is not able to compile a simple test program.

It fails with the following output:

Change Dir: ....../flann/build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_78471/fast"
/usr/bin/make -f CMakeFiles/cmTC_78471.dir/build.make 
CMakeFiles/cmTC_78471.dir/build
make[1]: Entering directory '....../flann/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_78471.dir/testCCompiler.c.o
....../RPi/bin/arm-rpi-linux-gnueabihf-gcc --sysroot=....../rootfs -o
CMakeFiles/cmTC_78471.dir/testCCompiler.c.o -c 
....../flann/build/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTC_78471
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_78471.dir/link.txt 
--verbose=1
....../RPi/bin/arm-rpi-linux-gnueabihf-gcc --sysroot=....../rootfs -rdynamic
CMakeFiles/cmTC_78471.dir/testCCompiler.c.o -o cmTC_78471
....../RPi/lib/gcc/arm-rpi-linux-gnueabihf/8.3.0/../../../../arm-rpi-linux-gnueabihf/bin/ld: 
cannot find crt1.o: No such file or directory
....../RPi/lib/gcc/arm-rpi-linux-gnueabihf/8.3.0/../../../../arm-rpi-linux-gnueabihf/bin/ld: 
cannot find crti.o: No such file or directory
collect2: error: ld returned 1 exit status
make[1]: *** [CMakeFiles/cmTC_78471.dir/build.make:87: cmTC_78471] Error 1
make[1]: Leaving directory '....../flann/build/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_78471/fast] Error 2




CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:24 (project)


To be more specific, I'm trying to cross compile flann 
(https://github.com/mariusmuja/flann) for raspberry pi 3B 
(https://www.raspberrypi.org/products/raspberry-pi-3-model-b/) .


Can anybody please give me a hand?


Cheers


-- 
Dr. Pei Jia CEO of Longer Vision Technology (Canada) Ltd.
Website: https://www.longervision.ca
Email: jiapei at longervision.com <mailto:jiapei at longervision.com>
cell phone in Canada: 778-863-5816 <tel:+17788635816>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190908/1fc04ec0/attachment.html>

From isuruf at gmail.com  Sun Sep  8 15:07:51 2019
From: isuruf at gmail.com (Isuru Fernando)
Date: Sun, 8 Sep 2019 14:07:51 -0500
Subject: [CMake] try_compile with multiple include directories
Message-ID: <CA+01voPTFhjzX8291703ZCwrOYJv66gx-y2eUuoXDe0e9ACfYg@mail.gmail.com>

Hello,

I can use the following to get try_compile to include one directory.

CMAKE_FLAGS "-DINCLUDE_DIRECTORIES=dir1"

How do you use try_compile when I have multiple directories to pass to it?

Isuru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190908/a8f59d55/attachment.html>

From kyle.edwards at kitware.com  Mon Sep  9 10:04:36 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Mon, 09 Sep 2019 10:04:36 -0400
Subject: [CMake] try_compile with multiple include directories
In-Reply-To: <CA+01voPTFhjzX8291703ZCwrOYJv66gx-y2eUuoXDe0e9ACfYg@mail.gmail.com>
References: <CA+01voPTFhjzX8291703ZCwrOYJv66gx-y2eUuoXDe0e9ACfYg@mail.gmail.com>
Message-ID: <1568037876.16243.2.camel@kitware.com>

On Sun, 2019-09-08 at 14:07 -0500, Isuru Fernando wrote:
> Hello,
> 
> I can use the following to get try_compile to include one directory.
> 
> CMAKE_FLAGS "-DINCLUDE_DIRECTORIES=dir1"
> 
> How do you use try_compile when I have multiple directories to pass
> to it?
> 
> Isuru

Use a semicolon:

CMAKE_FLAGS "-DINCLUDE_DIRECTORIES=dir1;dir2"

Kyle

From isuruf at gmail.com  Mon Sep  9 17:57:03 2019
From: isuruf at gmail.com (Isuru Fernando)
Date: Mon, 9 Sep 2019 16:57:03 -0500
Subject: [CMake] try_compile with multiple include directories
In-Reply-To: <1568037876.16243.2.camel@kitware.com>
References: <CA+01voPTFhjzX8291703ZCwrOYJv66gx-y2eUuoXDe0e9ACfYg@mail.gmail.com>
 <1568037876.16243.2.camel@kitware.com>
Message-ID: <CA+01voN4M-o56BsJxTOrZF-LhZgkBvZ=UTabVwdv5p4mfFzVwQ@mail.gmail.com>

Yes, semicolon worked.

Thanks Kyle and Jakub for the responses.

Isuru

On Mon, Sep 9, 2019 at 9:04 AM Kyle Edwards <kyle.edwards at kitware.com>
wrote:

> On Sun, 2019-09-08 at 14:07 -0500, Isuru Fernando wrote:
> > Hello,
> >
> > I can use the following to get try_compile to include one directory.
> >
> > CMAKE_FLAGS "-DINCLUDE_DIRECTORIES=dir1"
> >
> > How do you use try_compile when I have multiple directories to pass
> > to it?
> >
> > Isuru
>
> Use a semicolon:
>
> CMAKE_FLAGS "-DINCLUDE_DIRECTORIES=dir1;dir2"
>
> Kyle
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190909/ad60b3ac/attachment.html>

From avraham.shukron at gmail.com  Wed Sep 11 14:40:56 2019
From: avraham.shukron at gmail.com (Avraham Shukron)
Date: Wed, 11 Sep 2019 21:40:56 +0300
Subject: [CMake] Should header files be listed for a target?
Message-ID: <CAJX3zAu6DvmOSbReyQc8MJMaK7kKtR_BroDvaeWU54WjE7zfYw@mail.gmail.com>

Hi!

I'm pretty new to cmake and I came across a question which I could not find
any information about in the official documentation or blog posts.

When adding a target through add_library / add_executable - should the
header files of the target also be listed?
The question also applies to target_sources I guess.

On one hand - as far as I can tell it compiles perfectly fine without doing
so, and the implicit dependency is also recognized (e.g if the header
changes - the target will be recompiled)
In addition most of the online examples do not list headers.

On the other hand - it seems wrong not to list them. They ARE part of the
target, even if they do not passed to the compiler directly.
I can also assume that some IDEs will want to know about the existence of
these headers and their relationship with the target.

So what is the correct answer? should header files be listed as part of the
target?

Another question - how does cmake know to create the dependency between the
target and the header file, even when it is not listed explicitly?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190911/a98c2dd7/attachment.html>

From kyle.edwards at kitware.com  Wed Sep 11 14:49:28 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Wed, 11 Sep 2019 14:49:28 -0400
Subject: [CMake] Should header files be listed for a target?
In-Reply-To: <CAJX3zAu6DvmOSbReyQc8MJMaK7kKtR_BroDvaeWU54WjE7zfYw@mail.gmail.com>
References: <CAJX3zAu6DvmOSbReyQc8MJMaK7kKtR_BroDvaeWU54WjE7zfYw@mail.gmail.com>
Message-ID: <1568227768.16243.9.camel@kitware.com>

On Wed, 2019-09-11 at 21:40 +0300, Avraham Shukron wrote:
> Hi!
> 
> I'm pretty new to cmake and I came across a question which I could
> not find any information about in the official documentation or blog
> posts.
> 
> When adding a target through add_library / add_executable - should
> the header files of the target also be listed?
> The question also applies to target_sources I guess.
> 
> On one hand - as far?as I can tell it compiles perfectly fine without
> doing so, and the implicit dependency is also recognized (e.g if the
> header changes - the target will be recompiled)
> In addition most of the online examples do not list headers.
> 
> On the other hand - it seems wrong not to list them. They ARE part of
> the target, even if they do not passed to the compiler directly.
> I can also assume that some IDEs will want to know about the
> existence of these headers and their relationship with the target.
> 
> So what is the correct answer? should header files be listed as part
> of the target?

You can list them or not list them. CMake will recognize them as header
files and ignore them (not attempt to compile them.) It's a matter of
personal preference. CMake's own CMake script lists them, but there are
plenty of projects that don't and work just fine.

> Another question - how does cmake know to create the
> dependency?between the target and the header file, even when it is
> not listed explicitly?

It uses GCC's -MD and -MF options (and the equivalents for other
compilers), which spits out the header dependency information.

Kyle

From avraham.shukron at gmail.com  Wed Sep 11 15:00:52 2019
From: avraham.shukron at gmail.com (Avraham Shukron)
Date: Wed, 11 Sep 2019 22:00:52 +0300
Subject: [CMake] Should header files be listed for a target?
In-Reply-To: <1568227768.16243.9.camel@kitware.com>
References: <CAJX3zAu6DvmOSbReyQc8MJMaK7kKtR_BroDvaeWU54WjE7zfYw@mail.gmail.com>
 <1568227768.16243.9.camel@kitware.com>
Message-ID: <CAJX3zAtkbmZ5R0mny0d86qzzSs+irbH1i3LUqGiGRsQ2AWwAwQ@mail.gmail.com>

On Wed, Sep 11, 2019 at 9:49 PM Kyle Edwards <kyle.edwards at kitware.com>
wrote:

> You can list them or not list them. CMake will recognize them as header
> files and ignore them (not attempt to compile them.) It's a matter of
> personal preference. CMake's own CMake script lists them, but there are
> plenty of projects that don't and work just fine.


And it far as IDE generators (Xcode, CodeBlocks etc) go - don't they care
about headers?


> > Another question - how does cmake know to create the
> > dependency between the target and the header file, even when it is
> > not listed explicitly?
>
> It uses GCC's -MD and -MF options (and the equivalents for other
> compilers), which spits out the header dependency information.


That is awesome. Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190911/265ab633/attachment.html>

From kyle.edwards at kitware.com  Wed Sep 11 15:22:04 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Wed, 11 Sep 2019 15:22:04 -0400
Subject: [CMake] Should header files be listed for a target?
In-Reply-To: <CAJX3zAtkbmZ5R0mny0d86qzzSs+irbH1i3LUqGiGRsQ2AWwAwQ@mail.gmail.com>
References: <CAJX3zAu6DvmOSbReyQc8MJMaK7kKtR_BroDvaeWU54WjE7zfYw@mail.gmail.com>
 <1568227768.16243.9.camel@kitware.com>
 <CAJX3zAtkbmZ5R0mny0d86qzzSs+irbH1i3LUqGiGRsQ2AWwAwQ@mail.gmail.com>
Message-ID: <1568229724.16243.11.camel@kitware.com>

On Wed, 2019-09-11 at 22:00 +0300, Avraham Shukron wrote:
> 
> 
> On Wed, Sep 11, 2019 at 9:49 PM Kyle Edwards <kyle.edwards at kitware.co
> m> wrote:
> > You can list them or not list them. CMake will recognize them as
> > header
> > files and ignore them (not attempt to compile them.) It's a matter
> > of
> > personal preference. CMake's own CMake script lists them, but there
> > are
> > plenty of projects that don't and work just fine.
> And it far as IDE generators (Xcode, CodeBlocks etc) go - don't they
> care about headers?

Yes, the headers are more important for IDE generators than they are
for Make/Ninja (though, AFAIK, they still don't affect the build, just
the files that the developer sees in the generated project in the IDE.)

Kyle

From neundorf at kde.org  Wed Sep 11 16:39:51 2019
From: neundorf at kde.org (Alexander Neundorf)
Date: Wed, 11 Sep 2019 22:39:51 +0200
Subject: [CMake] Should header files be listed for a target?
In-Reply-To: <1568229724.16243.11.camel@kitware.com>
References: <CAJX3zAu6DvmOSbReyQc8MJMaK7kKtR_BroDvaeWU54WjE7zfYw@mail.gmail.com>
 <CAJX3zAtkbmZ5R0mny0d86qzzSs+irbH1i3LUqGiGRsQ2AWwAwQ@mail.gmail.com>
 <1568229724.16243.11.camel@kitware.com>
Message-ID: <3283913.OgZ7btPWKF@linux-lma8>

On Mittwoch, 11. September 2019 21:22:04 CEST Kyle Edwards via CMake wrote:
> On Wed, 2019-09-11 at 22:00 +0300, Avraham Shukron wrote:
> > On Wed, Sep 11, 2019 at 9:49 PM Kyle Edwards <kyle.edwards at kitware.co
> > 
> > m> wrote:
> > > You can list them or not list them. CMake will recognize them as
> > > header
> > > files and ignore them (not attempt to compile them.) It's a matter
> > > of
> > > personal preference. CMake's own CMake script lists them, but there
> > > are
> > > plenty of projects that don't and work just fine.
> > 
> > And it far as IDE generators (Xcode, CodeBlocks etc) go - don't they
> > care about headers?
> 
> Yes, the headers are more important for IDE generators than they are
> for Make/Ninja (though, AFAIK, they still don't affect the build, just
> the files that the developer sees in the generated project in the IDE.)

it depends.
If you use e.g. the kate project generator, and your project is in svn or git, 
kate retrieves the full list of files via svn/git.
Some generators check whether there is a foo.h in the same directory if there 
is a foo.cpp listed, and add this automatically.

Alex




From mike.jackson at bluequartz.net  Wed Sep 11 17:33:46 2019
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Wed, 11 Sep 2019 17:33:46 -0400
Subject: [CMake] Setting RPATH lookup on macOS
Message-ID: <FD95FC72-22BB-4E1A-BF1A-336A91731558@bluequartz.net>

Already looked on google and at the CMake documentation but everything listed does not seem to work so here is the setup.

I am using MKL and I have a home grown FindMKL since there isn?t an official one. Inside that is the typical find_library() calls which will find the libraries just fine. One of those libraries is a dynamic library (.dylib). Using otool -L on that library the install_name is encoded as @rpath. 

Now I have my add_executable(foo?) and target_link_libraries (Foo ${MKL_LIBRARIES} ).

Everything compiles and links fine. The issue is at runtime. The app will not launch because libmkl_rt.dylib is not loaded because the path to that library is not encoded into the executable.

639:[mjackson at ferb:ifort-release]$ otool -l Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
         name @rpath/libEbsdLib.dylib (offset 24)
         name @rpath/libmkl_rt.dylib (offset 24)
         name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset 24)
         name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset 24)
         name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (offset 24)
         name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset 24)
         name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
         name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
         path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib (offset 12)
         path /Users/Shared/EMsoft_SDK-ifort/Qt5.12.3/5.12.3/clang_64/lib (offset 12)


Oddly the Qt libraries and one of my own libraries do get their rpaths encoded. I feel like I need to append to the RPATH that gets encoded into the executable but I am not really figuring out how to do that.

Help....

--
Michael Jackson | Owner, President
      BlueQuartz Software
[e] mike.jackson at bluequartz.net
[w] www.bluequartz.net <http://www.bluequartz.net>



From kyle.edwards at kitware.com  Wed Sep 11 17:41:58 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Wed, 11 Sep 2019 17:41:58 -0400
Subject: [CMake] Setting RPATH lookup on macOS
In-Reply-To: <FD95FC72-22BB-4E1A-BF1A-336A91731558@bluequartz.net>
References: <FD95FC72-22BB-4E1A-BF1A-336A91731558@bluequartz.net>
Message-ID: <1568238118.16243.12.camel@kitware.com>

On Wed, 2019-09-11 at 17:33 -0400, Michael Jackson wrote:
> Already looked on google and at the CMake documentation but
> everything listed does not seem to work so here is the setup.
> 
> I am using MKL and I have a home grown FindMKL since there isn?t an
> official one. Inside that is the typical find_library() calls which
> will find the libraries just fine. One of those libraries is a
> dynamic library (.dylib). Using otool -L on that library the
> install_name is encoded as @rpath.?
> 
> Now I have my add_executable(foo?) and target_link_libraries (Foo
> ${MKL_LIBRARIES} ).
> 
> Everything compiles and links fine. The issue is at runtime. The app
> will not launch because libmkl_rt.dylib is not loaded because the
> path to that library is not encoded into the executable.
> 
> 639:[mjackson at ferb:ifort-release]$ otool -l
> Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
> ?????????name @rpath/libEbsdLib.dylib (offset 24)
> ?????????name @rpath/libmkl_rt.dylib (offset 24)
> ?????????name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset
> 24)
> ?????????name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset
> 24)
> ?????????name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent
> (offset 24)
> ?????????name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset
> 24)
> ?????????name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
> ?????????name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
> ?????????path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib
> (offset 12)
> ?????????path /Users/Shared/EMsoft_SDK-
> ifort/Qt5.12.3/5.12.3/clang_64/lib (offset 12)
> 
> 
> Oddly the Qt libraries and one of my own libraries do get their
> rpaths encoded. I feel like I need to append to the RPATH that gets
> encoded into the executable but I am not really figuring out how to
> do that.
> 
> Help....

Have you looked at the BUILD_RPATH and INSTALL_RPATH properties?

https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH.html
https://cmake.org/cmake/help/latest/prop_tgt/INSTALL_RPATH.html

Kyle

From mike.jackson at bluequartz.net  Wed Sep 11 17:52:37 2019
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Wed, 11 Sep 2019 17:52:37 -0400
Subject: [CMake] Setting RPATH lookup on macOS
In-Reply-To: <1568238118.16243.12.camel@kitware.com>
References: <FD95FC72-22BB-4E1A-BF1A-336A91731558@bluequartz.net>
 <1568238118.16243.12.camel@kitware.com>
Message-ID: <DC0A72F9-05A9-482F-9A76-031A17083DA1@bluequartz.net>


?On 9/11/19, 5:42 PM, "Kyle Edwards" <kyle.edwards at kitware.com> wrote:

    On Wed, 2019-09-11 at 17:33 -0400, Michael Jackson wrote:
    > Already looked on google and at the CMake documentation but
    > everything listed does not seem to work so here is the setup.
    > 
    > I am using MKL and I have a home grown FindMKL since there isn?t an
    > official one. Inside that is the typical find_library() calls which
    > will find the libraries just fine. One of those libraries is a
    > dynamic library (.dylib). Using otool -L on that library the
    > install_name is encoded as @rpath. 
    > 
    > Now I have my add_executable(foo?) and target_link_libraries (Foo
    > ${MKL_LIBRARIES} ).
    > 
    > Everything compiles and links fine. The issue is at runtime. The app
    > will not launch because libmkl_rt.dylib is not loaded because the
    > path to that library is not encoded into the executable.
    > 
    > 639:[mjackson at ferb:ifort-release]$ otool -l
    > Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
    >          name @rpath/libEbsdLib.dylib (offset 24)
    >          name @rpath/libmkl_rt.dylib (offset 24)
    >          name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset
    > 24)
    >          name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset
    > 24)
    >          name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent
    > (offset 24)
    >          name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset
    > 24)
    >          name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
    >          name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
    >          path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib
    > (offset 12)
    >          path /Users/Shared/EMsoft_SDK-
    > ifort/Qt5.12.3/5.12.3/clang_64/lib (offset 12)
    > 
    > 
    > Oddly the Qt libraries and one of my own libraries do get their
    > rpaths encoded. I feel like I need to append to the RPATH that gets
    > encoded into the executable but I am not really figuring out how to
    > do that.
    > 
    > Help....
    
    Have you looked at the BUILD_RPATH and INSTALL_RPATH properties?
    
    https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH.html
    https://cmake.org/cmake/help/latest/prop_tgt/INSTALL_RPATH.html
    
    Kyle
    
<smacks forehead with hand...> Missed BUILD_RPATH property. Found every other one.... THanks

--
Mike Jackson




From ashish.sadanandan at gmail.com  Wed Sep 11 20:26:27 2019
From: ashish.sadanandan at gmail.com (Ashish Sadanandan)
Date: Wed, 11 Sep 2019 18:26:27 -0600
Subject: [CMake] Packaging a directory with CPack RPM
Message-ID: <CAN44U22Un21wbT0QWCQPim816YFn_sbTE4QTNit2njVnvxLC-Q@mail.gmail.com>

Hello,
I'm using CPack to create RPMs for an application. I have this working but
the CPack step is quite slow. While investigating this, I noticed that all
files in a directory I'm packaging, which contains a large number of small
files, is being listed in the spec file.

For instance, say I have

    set(CPACK_PACKAGING_INSTALL_PREFIX /opt/myapp)
    install(DIRECTORY ${CMAKE_BINARY_DIR}/myapp/foo
            DESTINATION foo
            COMPONENT myapp
    )

In the %files section I see

    %files
    %dir /opt/myapp/foo
    " /opt/myapp/foo/file1"
    " /opt/myapp/foo/file2"
    ...
    " /opt/myapp/foo/file60000"

If I were writing the spec file by hand, this entire section could be
replaced by a single line

    %files
    /opt/myapp/foo

RPM will package all files within the directory if you specify the
directory under %files (
http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html - the
"The %dir Directive" section)

Is there an option to list just the directory instead of recursively
listing all contained files within the directory?

I'm not claiming this is the reason for CPack being slow, I came across
this while investigating performance and if nothing else, this will result
in a cleaner looking spec file.

Best regards,
Ashish.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190911/0465033e/attachment.html>

From sancelot at numalliance.com  Thu Sep 12 03:54:55 2019
From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=)
Date: Thu, 12 Sep 2019 09:54:55 +0200
Subject: [CMake] can not import target external lib before being build
Message-ID: <4d1942d9-7ed8-ae52-99bd-43ab9f884414@numalliance.com>

Hi,

I am using this cmake snippet in order to build an external library


# ------ QGLViewer ----------
set(QGLVIEWER_FILES 
${CMAKE_BINARY_DIR}/libQGLViewer-2.7.1/QGLViewer/qglviewer.h)

get_target_property (QT_QMAKE_EXECUTABLE Qt5::qmake IMPORTED_LOCATION)

add_custom_command(OUTPUT ${QGLVIEWER_FILES}
 ? COMMAND? tar xzf 
"${CMAKE_CURRENT_SOURCE_DIR}/libQGLViewer-2.7.1.tar.gz" --strip 1
 ? COMMAND ${QT_QMAKE_EXECUTABLE} -o QMakefile
 ? COMMAND make -f QMakefile
#? COMMAND ${CMAKE_COMMAND} -E touch ${LIBFOO_TAR_HEADERS}
 ? WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/libQGLViewer-2.7.1"
 ? DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/libQGLViewer-2.7.1.tar.gz"
 ? COMMENT "Unpacking libQGLViewer-2.7.1.tar.gz"
 ? VERBATIM
)

add_custom_target(qglviewer_untar DEPENDS ${QGLVIEWER_FILES})

add_library(qglviewer SHARED IMPORTED)
add_dependencies(qglviewer qglviewer_untar)

# link qglviewer
set_target_properties(qglviewer PROPERTIES
 ????????????????????? IMPORTED_LOCATION 
"${CMAKE_CURRENT_BINARY_DIR}/libQGLViewer-2.7.1/QGLViewer/libQGLViewer-qt5.so"
 ????????????????????? INTERFACE_INCLUDE_DIRECTORIES 
"${CMAKE_CURRENT_BINARY_DIR}/libQGLViewer-2.7.1")


Unfortunately, cmake replies with the next error when configuring :


CMake Error in API_COLLISION/CMakeLists.txt:
 ? Imported target "qglviewer" includes non-existent path

"/tmp/OK/BASE_SILFAX_SAFETY/build/API_COLLISION/libQGLViewer-2.7.1"

 ? in its INTERFACE_INCLUDE_DIRECTORIES.? Possible reasons include:

 ? * The path was deleted, renamed, or moved to another location.

 ? * An install or uninstall procedure did not complete successfully.

 ? * The installation package was faulty and references files it does not
 ? provide.



CMake Error in API_COLLISION/CMakeLists.txt:
 ? Imported target "qglviewer" includes non-existent path

"/tmp/OK/BASE_SILFAX_SAFETY/build/API_COLLISION/libQGLViewer-2.7.1"

 ? in its INTERFACE_INCLUDE_DIRECTORIES.? Possible reasons include:

 ? * The path was deleted, renamed, or moved to another location.

 ? * An install or uninstall procedure did not complete successfully.

 ? * The installation package was faulty and references files it does not
 ? provide.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190912/b0a858d1/attachment.html>

From eric.noulard at gmail.com  Thu Sep 12 06:57:44 2019
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 12 Sep 2019 12:57:44 +0200
Subject: [CMake] Packaging a directory with CPack RPM
In-Reply-To: <CAN44U22Un21wbT0QWCQPim816YFn_sbTE4QTNit2njVnvxLC-Q@mail.gmail.com>
References: <CAN44U22Un21wbT0QWCQPim816YFn_sbTE4QTNit2njVnvxLC-Q@mail.gmail.com>
Message-ID: <CAPASGLr-bBnHbfZMHQxq5vCTgMwxYYGKgZ2e2ioWiVUTjibamA@mail.gmail.com>

Le jeu. 12 sept. 2019 ? 02:27, Ashish Sadanandan <
ashish.sadanandan at gmail.com> a ?crit :

> Hello,
> I'm using CPack to create RPMs for an application. I have this working but
> the CPack step is quite slow. While investigating this, I noticed that all
> files in a directory I'm packaging, which contains a large number of small
> files, is being listed in the spec file.
>
> For instance, say I have
>
>     set(CPACK_PACKAGING_INSTALL_PREFIX /opt/myapp)
>     install(DIRECTORY ${CMAKE_BINARY_DIR}/myapp/foo
>             DESTINATION foo
>             COMPONENT myapp
>     )
>
> In the %files section I see
>
>     %files
>     %dir /opt/myapp/foo
>     " /opt/myapp/foo/file1"
>     " /opt/myapp/foo/file2"
>     ...
>     " /opt/myapp/foo/file60000"
>
> If I were writing the spec file by hand, this entire section could be
> replaced by a single line
>
>     %files
>     /opt/myapp/foo
>

CPack has no idea that the list of files are coming from an installed
*directory*, because CPack is not doing the install CMake is.
Thus CPackRPM and other CPack generators collect all installed bits inside
a given [temporary] prefix directory.

Now may be you can tell CPack to ignore some of you installed
files/directory by using: CPACK_RPM_USER_FILELIST

https://cmake.org/cmake/help/v3.15/cpack_gen/rpm.html#cpack_gen:CPack%20RPM%20Generator



> RPM will package all files within the directory if you specify the
> directory under %files (
> http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html - the
> "The %dir Directive" section)
> Is there an option to list just the directory instead of recursively
> listing all contained files within the directory?
>

AFAIK, No there is not.


I'm not claiming this is the reason for CPack being slow, I came across
> this while investigating performance and if nothing else, this will result
> in a cleaner looking spec file.
>

For performance sake you can
try CPACK_RPM_USER_BINARY_SPECFILE,
CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
and handcraft your "user" spec file in order to see if it helps the
packaging performance.
and/or you can set CPACK_RPM_PACKAGE_DEBUG to 1 in order to get more timed
traces of CPackRPM execution.


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190912/d54c8e7a/attachment-0001.html>

From juan.e.sanchez at gmail.com  Thu Sep 12 11:34:55 2019
From: juan.e.sanchez at gmail.com (Juan Sanchez)
Date: Thu, 12 Sep 2019 10:34:55 -0500
Subject: [CMake] Setting RPATH lookup on macOS
In-Reply-To: <FD95FC72-22BB-4E1A-BF1A-336A91731558@bluequartz.net>
References: <FD95FC72-22BB-4E1A-BF1A-336A91731558@bluequartz.net>
Message-ID: <CAEHOsR3iiaQJa3EgT3bi8twEq3jLAU=Wcjq0VLJx3H7NKCvQ5w@mail.gmail.com>

The macOS install_name_tool can be used to change the RPATH of your
binaries.  It can also be used to set the path for each of the libraries to
be loaded.  For a python module I compile, I copy each of its dylib into
the appropriate directory relative to my shared library.  I then use the
install_name_tool to change from an absolute path to a path relative to
@loader_path.

install_name_tool -change $j "@loader_path/../gcc/`basename $j`" $i
where $j is the full path output from "otool -L" and "@loader_path/../gcc"
would point to a directory "gcc" relative to the directory containing my
python module.

For a binary executable, I would explore placing required dylib files into
a directory relative to @executable_path.

Regards,

Juan



On Wed, Sep 11, 2019 at 4:33 PM Michael Jackson <mike.jackson at bluequartz.net>
wrote:

> Already looked on google and at the CMake documentation but everything
> listed does not seem to work so here is the setup.
>
> I am using MKL and I have a home grown FindMKL since there isn?t an
> official one. Inside that is the typical find_library() calls which will
> find the libraries just fine. One of those libraries is a dynamic library
> (.dylib). Using otool -L on that library the install_name is encoded as
> @rpath.
>
> Now I have my add_executable(foo?) and target_link_libraries (Foo
> ${MKL_LIBRARIES} ).
>
> Everything compiles and links fine. The issue is at runtime. The app will
> not launch because libmkl_rt.dylib is not loaded because the path to that
> library is not encoded into the executable.
>
> 639:[mjackson at ferb:ifort-release]$ otool -l
> Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
>          name @rpath/libEbsdLib.dylib (offset 24)
>          name @rpath/libmkl_rt.dylib (offset 24)
>          name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset 24)
>          name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset 24)
>          name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent
> (offset 24)
>          name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset 24)
>          name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
>          name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
>          path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib
> (offset 12)
>          path /Users/Shared/EMsoft_SDK-ifort/Qt5.12.3/5.12.3/clang_64/lib
> (offset 12)
>
>
> Oddly the Qt libraries and one of my own libraries do get their rpaths
> encoded. I feel like I need to append to the RPATH that gets encoded into
> the executable but I am not really figuring out how to do that.
>
> Help....
>
> --
> Michael Jackson | Owner, President
>       BlueQuartz Software
> [e] mike.jackson at bluequartz.net
> [w] www.bluequartz.net <http://www.bluequartz.net>
>
>
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190912/094c412f/attachment.html>

From mike.jackson at bluequartz.net  Thu Sep 12 11:56:09 2019
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Thu, 12 Sep 2019 11:56:09 -0400
Subject: [CMake] Setting RPATH lookup on macOS
In-Reply-To: <CAEHOsR3iiaQJa3EgT3bi8twEq3jLAU=Wcjq0VLJx3H7NKCvQ5w@mail.gmail.com>
References: <FD95FC72-22BB-4E1A-BF1A-336A91731558@bluequartz.net>
 <CAEHOsR3iiaQJa3EgT3bi8twEq3jLAU=Wcjq0VLJx3H7NKCvQ5w@mail.gmail.com>
Message-ID: <09DE3B57-479D-4DE7-93DC-2E9DB0FF53F1@bluequartz.net>

On macOS you really should _not_ have to copy the libraries into the build tree. I have never had to do that in 10 years of our product (Windows is a different story). The trick is setting the correct options to add in the paths to the libraries into the RPATH of the executable/library. (at least on macOS & Linux systems).

 

--

Mike Jackson

 

 

From: Juan Sanchez <juan.e.sanchez at gmail.com>
Date: Thursday, September 12, 2019 at 11:35 AM
To: Michael Jackson <mike.jackson at bluequartz.net>
Cc: CMake <cmake at cmake.org>
Subject: Re: [CMake] Setting RPATH lookup on macOS

 

The macOS install_name_tool can be used to change the RPATH of your binaries.  It can also be used to set the path for each of the libraries to be loaded.  For a python module I compile, I copy each of its dylib into the appropriate directory relative to my shared library.  I then use the install_name_tool to change from an absolute path to a path relative to @loader_path.

 

install_name_tool -change $j "@loader_path/../gcc/`basename $j`" $i
where $j is the full path output from "otool -L" and "@loader_path/../gcc" would point to a directory "gcc" relative to the directory containing my python module.

For a binary executable, I would explore placing required dylib files into a directory relative to @executable_path.

Regards,

 

Juan


 

On Wed, Sep 11, 2019 at 4:33 PM Michael Jackson <mike.jackson at bluequartz.net> wrote:

Already looked on google and at the CMake documentation but everything listed does not seem to work so here is the setup.

I am using MKL and I have a home grown FindMKL since there isn?t an official one. Inside that is the typical find_library() calls which will find the libraries just fine. One of those libraries is a dynamic library (.dylib). Using otool -L on that library the install_name is encoded as @rpath. 

Now I have my add_executable(foo?) and target_link_libraries (Foo ${MKL_LIBRARIES} ).

Everything compiles and links fine. The issue is at runtime. The app will not launch because libmkl_rt.dylib is not loaded because the path to that library is not encoded into the executable.

639:[mjackson at ferb:ifort-release]$ otool -l Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
         name @rpath/libEbsdLib.dylib (offset 24)
         name @rpath/libmkl_rt.dylib (offset 24)
         name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset 24)
         name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset 24)
         name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (offset 24)
         name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset 24)
         name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
         name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
         path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib (offset 12)
         path /Users/Shared/EMsoft_SDK-ifort/Qt5.12.3/5.12.3/clang_64/lib (offset 12)


Oddly the Qt libraries and one of my own libraries do get their rpaths encoded. I feel like I need to append to the RPATH that gets encoded into the executable but I am not really figuring out how to do that.

Help....

--
Michael Jackson | Owner, President
      BlueQuartz Software
[e] mike.jackson at bluequartz.net
[w] www.bluequartz.net <http://www.bluequartz.net>


-- 

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 services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190912/9ef8b293/attachment-0001.html>

From juan.e.sanchez at gmail.com  Thu Sep 12 12:17:18 2019
From: juan.e.sanchez at gmail.com (Juan Sanchez)
Date: Thu, 12 Sep 2019 11:17:18 -0500
Subject: [CMake] Setting RPATH lookup on macOS
In-Reply-To: <09DE3B57-479D-4DE7-93DC-2E9DB0FF53F1@bluequartz.net>
References: <FD95FC72-22BB-4E1A-BF1A-336A91731558@bluequartz.net>
 <CAEHOsR3iiaQJa3EgT3bi8twEq3jLAU=Wcjq0VLJx3H7NKCvQ5w@mail.gmail.com>
 <09DE3B57-479D-4DE7-93DC-2E9DB0FF53F1@bluequartz.net>
Message-ID: <CAEHOsR2=DyPWm8Fwp8ASbqBFanzOuS+fQySHDToapmt5rc+77A@mail.gmail.com>

I never suggested copying files into the build tree.  The original
question was about how to locate libraries at runtime.  You don't
necessarily have to use @rpath, @executable_path is also a valid
option.  Another valid option one is to strip out @rpath and use
DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH.

If you want to set an rpath from cmake, you can also use target properties like:
INSTALL_RPATH
BUILD_WITH_INSTALL_RPATH

where BUILD_WITH_INSTALL_RPATH is useful if you don't want to use
CMake's install system.

Regards,

Juan

On Thu, Sep 12, 2019 at 10:56 AM Michael Jackson
<mike.jackson at bluequartz.net> wrote:
>
> On macOS you really should _not_ have to copy the libraries into the build tree. I have never had to do that in 10 years of our product (Windows is a different story). The trick is setting the correct options to add in the paths to the libraries into the RPATH of the executable/library. (at least on macOS & Linux systems).
>
>
>
> --
>
> Mike Jackson
>
>
>
>
>
> From: Juan Sanchez <juan.e.sanchez at gmail.com>
> Date: Thursday, September 12, 2019 at 11:35 AM
> To: Michael Jackson <mike.jackson at bluequartz.net>
> Cc: CMake <cmake at cmake.org>
> Subject: Re: [CMake] Setting RPATH lookup on macOS
>
>
>
> The macOS install_name_tool can be used to change the RPATH of your binaries.  It can also be used to set the path for each of the libraries to be loaded.  For a python module I compile, I copy each of its dylib into the appropriate directory relative to my shared library.  I then use the install_name_tool to change from an absolute path to a path relative to @loader_path.
>
>
>
> install_name_tool -change $j "@loader_path/../gcc/`basename $j`" $i
>
> where $j is the full path output from "otool -L" and "@loader_path/../gcc" would point to a directory "gcc" relative to the directory containing my python module.
>
> For a binary executable, I would explore placing required dylib files into a directory relative to @executable_path.
>
> Regards,
>
>
>
> Juan
>
>
>
> On Wed, Sep 11, 2019 at 4:33 PM Michael Jackson <mike.jackson at bluequartz.net> wrote:
>
> Already looked on google and at the CMake documentation but everything listed does not seem to work so here is the setup.
>
> I am using MKL and I have a home grown FindMKL since there isn?t an official one. Inside that is the typical find_library() calls which will find the libraries just fine. One of those libraries is a dynamic library (.dylib). Using otool -L on that library the install_name is encoded as @rpath.
>
> Now I have my add_executable(foo?) and target_link_libraries (Foo ${MKL_LIBRARIES} ).
>
> Everything compiles and links fine. The issue is at runtime. The app will not launch because libmkl_rt.dylib is not loaded because the path to that library is not encoded into the executable.
>
> 639:[mjackson at ferb:ifort-release]$ otool -l Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
>          name @rpath/libEbsdLib.dylib (offset 24)
>          name @rpath/libmkl_rt.dylib (offset 24)
>          name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset 24)
>          name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset 24)
>          name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (offset 24)
>          name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset 24)
>          name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
>          name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
>          path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib (offset 12)
>          path /Users/Shared/EMsoft_SDK-ifort/Qt5.12.3/5.12.3/clang_64/lib (offset 12)
>
>
> Oddly the Qt libraries and one of my own libraries do get their rpaths encoded. I feel like I need to append to the RPATH that gets encoded into the executable but I am not really figuring out how to do that.
>
> Help....
>
> --
> Michael Jackson | Owner, President
>       BlueQuartz Software
> [e] mike.jackson at bluequartz.net
> [w] www.bluequartz.net <http://www.bluequartz.net>
>
>
> --
>
> 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 services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From fifteenknots505 at gmail.com  Thu Sep 12 12:31:13 2019
From: fifteenknots505 at gmail.com (15 knots)
Date: Thu, 12 Sep 2019 18:31:13 +0200
Subject: [CMake] compile_commands.json question
Message-ID: <CANo-CZHegLx4w5ewoGKHmUT-y3Pd4bxqe+ROFTbO3mx-w9F9fQ@mail.gmail.com>

Hi all,

this is more a question to the cmake developers.

Older versions (3.15.0) of cmake produced short file names w/o spaces
on windows, when the path of the compiler executable contained spaces.
Now I have an issue [1] where compiler executable path contains spaces
with cmake 3.15.2.
Can anyone confirm whether the spaces are caused by changes made to
cmake after version 3.15.0?
Or could a user-supplied toolchain file cause the spaces?

Kind regards,
 Martin



[1] https://github.com/15knots/cmake4eclipse/issues/119#issuecomment-528716815

From twhall at umich.edu  Thu Sep 12 18:23:54 2019
From: twhall at umich.edu (Theodore Hall)
Date: Thu, 12 Sep 2019 18:23:54 -0400
Subject: [CMake] set_target_properties ( INTERFACE_INCLUDE_DIRECTORIES ...)
Message-ID: <CAGRUjbPBTxV1FPHSuHnhZZojvWEaibUumwY-9UquGrK0CR8=Qw@mail.gmail.com>

Greetings,

  set_target_properties(target PROPERTIES
    IMPORTED_LOCATION location
    IMPORTED_IMPLIB implib
    INTERFACE_INCLUDE_DIRECTORIES directory+
  )

Is there a way to assign more than one directory to
INTERFACE_INCLUDE_DIRECTORIES ?  The property name is plural, but every
attempt I've made to specify more than one directory has failed.  CMake
complains that either: I've passed the wrong number of arguments; or
concatenates all of them into one path which of course doesn't exist.

I've found a work-around using

  target_include_directories (target
    INTERFACE directory1
    INTERFACE directory2
  )

It just seems odd that a property with a plural name accepts only a
singular value.  I feel like I'm missing something.  I've tried wrapping
multiple directories in various kinds of brackets and quotes and separating
them with ; or , instead of whitespace.  (This is Windows, so : isn't a
path separator; the system PATH variable uses ; as the separator.)

Thanks for any enlightenment.

-- 

Ted Hall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190912/1bb7dd9b/attachment.html>

From craig.scott at crascit.com  Thu Sep 12 18:30:58 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Fri, 13 Sep 2019 08:30:58 +1000
Subject: [CMake] set_target_properties ( INTERFACE_INCLUDE_DIRECTORIES
 ...)
In-Reply-To: <CAGRUjbPBTxV1FPHSuHnhZZojvWEaibUumwY-9UquGrK0CR8=Qw@mail.gmail.com>
References: <CAGRUjbPBTxV1FPHSuHnhZZojvWEaibUumwY-9UquGrK0CR8=Qw@mail.gmail.com>
Message-ID: <CA+dygYk6Os4K5o3F8N6R=wzeGivGhDyssBU1xkt6nng_ArwsCw@mail.gmail.com>

On Fri, Sep 13, 2019 at 8:24 AM Theodore Hall <twhall at umich.edu> wrote:

> Greetings,
>
>   set_target_properties(target PROPERTIES
>     IMPORTED_LOCATION location
>     IMPORTED_IMPLIB implib
>     INTERFACE_INCLUDE_DIRECTORIES directory+
>   )
>
> Is there a way to assign more than one directory to
> INTERFACE_INCLUDE_DIRECTORIES ?  The property name is plural, but every
> attempt I've made to specify more than one directory has failed.  CMake
> complains that either: I've passed the wrong number of arguments; or
> concatenates all of them into one path which of course doesn't exist.
>

> I've found a work-around using
>
>   target_include_directories (target
>     INTERFACE directory1
>     INTERFACE directory2
>   )
>
> It just seems odd that a property with a plural name accepts only a
> singular value.  I feel like I'm missing something.  I've tried wrapping
> multiple directories in various kinds of brackets and quotes and separating
> them with ; or , instead of whitespace.  (This is Windows, so : isn't a
> path separator; the system PATH variable uses ; as the separator.)
>


OPTION A: Put quotes around a semi-colon separated string if using
set_target_properties():

set_target_properties(target PROPERTIES
    IMPORTED_LOCATION location
    IMPORTED_IMPLIB implib
    INTERFACE_INCLUDE_DIRECTORIES "directory1;directory2"
  )

OPTION B: List multiple directories after just one INTERFACE keyword if
using target_include_directories():

  target_include_directories (target
    INTERFACE directory1 directory2
  )

Either option should work for all platforms, but note that option A will
overwrite any previous contents of INTERFACE_INCLUDED_DIRECTORIES whereas
option B will append to any previous contents. For that reason, I'd
generally recommend option B.

>
-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
Consulting services (CMake, C++, build/release processes):
https://crascit.com/services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190913/bcc7a166/attachment.html>

From twhall at umich.edu  Fri Sep 13 00:23:50 2019
From: twhall at umich.edu (Theodore Hall)
Date: Fri, 13 Sep 2019 00:23:50 -0400
Subject: [CMake] set_target_properties ( INTERFACE_INCLUDE_DIRECTORIES
 ...)
In-Reply-To: <CA+dygYk6Os4K5o3F8N6R=wzeGivGhDyssBU1xkt6nng_ArwsCw@mail.gmail.com>
References: <CAGRUjbPBTxV1FPHSuHnhZZojvWEaibUumwY-9UquGrK0CR8=Qw@mail.gmail.com>
 <CA+dygYk6Os4K5o3F8N6R=wzeGivGhDyssBU1xkt6nng_ArwsCw@mail.gmail.com>
Message-ID: <CAGRUjbMruYdePT=XAeDhNpfRuscgrATFt_S8w6RpKxfp51U8dQ@mail.gmail.com>

On Thu, Sep 12, 2019 at 6:31 PM Craig Scott <craig.scott at crascit.com> wrote:

OPTION A: Put quotes around a semi-colon separated string if using
> set_target_properties():
>

Many thanks.  I had tried quotes, and I had tried a semi-colon, and I
thought that I had tried them together, but evidently I missed that
permutation.

I'm actually sticking with OPTION B anyway -- it seems cleaner.  But I was
mystified looking for OPTION A.

-- 

Ted Hall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190913/bc2c7744/attachment-0001.html>

From petr.kmoch at gmail.com  Fri Sep 13 02:51:17 2019
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Fri, 13 Sep 2019 08:51:17 +0200
Subject: [CMake] set_target_properties ( INTERFACE_INCLUDE_DIRECTORIES
 ...)
In-Reply-To: <CAGRUjbMruYdePT=XAeDhNpfRuscgrATFt_S8w6RpKxfp51U8dQ@mail.gmail.com>
References: <CAGRUjbPBTxV1FPHSuHnhZZojvWEaibUumwY-9UquGrK0CR8=Qw@mail.gmail.com>
 <CA+dygYk6Os4K5o3F8N6R=wzeGivGhDyssBU1xkt6nng_ArwsCw@mail.gmail.com>
 <CAGRUjbMruYdePT=XAeDhNpfRuscgrATFt_S8w6RpKxfp51U8dQ@mail.gmail.com>
Message-ID: <CAKohaZfC-php2p9TfUivf_ixTXxQTX+roV0GtYMwDgojw7LjbA@mail.gmail.com>

For completeness, there is also OPTION C:

  set_property(TARGET target PROPERTY INTERFACE_INCLUDE_DIRECTORIES
directory1 directory2)

set_target_properties() is a shorthand for setting several properties at
once, so it assumes its arguments are prop value prop value. If you need
finer control, such as appending or easy way to pass multiple values, use
the full power of set_property().

Petr

On Fri, 13 Sep 2019 at 06:24, Theodore Hall <twhall at umich.edu> wrote:

> On Thu, Sep 12, 2019 at 6:31 PM Craig Scott <craig.scott at crascit.com>
> wrote:
>
> OPTION A: Put quotes around a semi-colon separated string if using
>> set_target_properties():
>>
>
> Many thanks.  I had tried quotes, and I had tried a semi-colon, and I
> thought that I had tried them together, but evidently I missed that
> permutation.
>
> I'm actually sticking with OPTION B anyway -- it seems cleaner.  But I was
> mystified looking for OPTION A.
>
> --
>
> Ted Hall
>
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190913/8409386e/attachment.html>

From s-morris at n-eos.com  Fri Sep 13 11:25:55 2019
From: s-morris at n-eos.com (Stephen Morris)
Date: Fri, 13 Sep 2019 15:25:55 +0000
Subject: [CMake] Preventing multiple definitions of metaObject methods
Message-ID: <VE1PR06MB6350074C36E89AF2A4A35BE1C9B30@VE1PR06MB6350.eurprd06.prod.outlook.com>

Suppose I have a class that derives from QObject, and contains the Q_OBJECT macro in its header file. When I compile it using AUTOMOC enabled, a "moc_myClass.cpp" file is created; if I manually include that file at the end of my 'myClass.cpp" file, then the moc file will be compiled there, otherwise CMake will take matters into its own hands and compile it anyway.

Now suppose make my class into a static library. The static library now contains the object code generated when moc_myClass.cpp was compiled.

I now include my static library from an application. Unless I enable AUTOMOC again, then I get a compilation error when Q_OBJECT is encountered. If I do enable it, then CMake generates a new moc_myClass.cpp file and, since it can't see the place where it was included in myClass.cpp, it goes ahead and recompiles it, placing the object code alongside the application's other object code.

Now, when the application links in the static library, it finds two definitions of moc_myClass.cpp's object code, and gives a multiple definition error.

All the ways I've come up with so far to work around this are so hacky that I'm embarrassed to mention them. There must be a proper way to handle this situation. Please can someone advise me what it is?

(N.B. I've been doing this for years with dynamic libraries are never encountered a problem, presumably because there the application doesn't get to see the inner workings of the library's object code. This issue does seem to be specific to static libraries, of which I have little prior experience).



From kyle.edwards at kitware.com  Fri Sep 13 11:53:34 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Fri, 13 Sep 2019 11:53:34 -0400
Subject: [CMake] Preventing multiple definitions of metaObject methods
In-Reply-To: <VE1PR06MB6350074C36E89AF2A4A35BE1C9B30@VE1PR06MB6350.eurprd06.prod.outlook.com>
References: <VE1PR06MB6350074C36E89AF2A4A35BE1C9B30@VE1PR06MB6350.eurprd06.prod.outlook.com>
Message-ID: <1568390014.16243.17.camel@kitware.com>

On Fri, 2019-09-13 at 15:25 +0000, Stephen Morris wrote:
> Suppose I have a class that derives from QObject, and contains the
> Q_OBJECT macro in its header file. When I compile it using AUTOMOC
> enabled, a "moc_myClass.cpp" file is created; if I manually include
> that file at the end of my 'myClass.cpp" file, then the moc file will
> be compiled there, otherwise CMake will take matters into its own
> hands and compile it anyway.
> 
> Now suppose make my class into a static library. The static library
> now contains the object code generated when moc_myClass.cpp was
> compiled.
> 
> I now include my static library from an application. Unless I enable
> AUTOMOC again, then I get a compilation error when Q_OBJECT is
> encountered. If I do enable it, then CMake generates a new
> moc_myClass.cpp file and, since it can't see the place where it was
> included in myClass.cpp, it goes ahead and recompiles it, placing the
> object code alongside the application's other object code.
> 
> Now, when the application links in the static library, it finds two
> definitions of moc_myClass.cpp's object code, and gives a multiple
> definition error.
> 
> All the ways I've come up with so far to work around this are so
> hacky that I'm embarrassed to mention them. There must be a proper
> way to handle this situation. Please can someone advise me what it
> is?
> 
> (N.B. I've been doing this for years with dynamic libraries are never
> encountered a problem, presumably because there the application
> doesn't get to see the inner workings of the library's object code.
> This issue does seem to be specific to static libraries, of which I
> have little prior experience).

Stephen,

Could you post a minimally reproducible example with CMakeLists.txt and
accompanying source code? I am currently working on a Qt-based project
with static libraries and have not encountered this issue.

Kyle

From kris.f.thielemans at gmail.com  Sat Sep 14 17:31:20 2019
From: kris.f.thielemans at gmail.com (Kris Thielemans)
Date: Sat, 14 Sep 2019 23:31:20 +0200
Subject: [CMake] find_path and double symbolic link
Message-ID: <022201d56b43$c067d9f0$41378dd0$@gmail.com>

Hi all

 

I have a weird situation where find_file finds a file (which is a link to a
link), but find_path sets an empty variable.

 

            find_path(CBLAS_INCLUDE_DIR cblas.h

                    PATHS /usr/include /usr/local/include )

            message(STATUS "KT CBLAS_INCLUDE_DIR ${CBLAS_INCLUDE_DIR}")

            find_file(CBLAS_INCLUDE cblas.h

                    PATHS /usr/include /usr/local/include  )

            message(STATUS "KT CBLAS_INCLUDE ${CBLAS_INCLUDE}")

 

Running CMake gives

 

-- KT CBLAS_INCLUDE_DIR 

-- KT CBLAS_INCLUDE /usr/include/x86_64-linux-gnu/cblas.h

 

Checking the file I see

 

$ ls -l /usr/include/x86_64-linux-gnu/cblas.h

lrwxrwxrwx 1 root root 42 Mar 14  2019 /usr/include/x86_64-linux-gnu/cblas.h
-> /etc/alternatives/cblas.h-x86_64-linux-gnu

build$ ls -l /etc/alternatives/cblas.h-x86_64-linux-gnu

lrwxrwxrwx 1 root root 46 Mar 14  2019
/etc/alternatives/cblas.h-x86_64-linux-gnu ->
/usr/include/x86_64-linux-gnu/cblas-openblas.h

$ ls -l /usr/include/x86_64-linux-gnu/cblas-openblas.h

-rw-r--r-- 1 root root 45648 Sep 19  2017
/usr/include/x86_64-linux-gnu/cblas-openblas.h

 

Any ideas ? Is this expected?

 

I'm running CMake 3.13.1 on Ubuntu 18.04.

 

Kris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190914/3b1e7656/attachment.html>

From s-morris at n-eos.com  Mon Sep 16 02:43:05 2019
From: s-morris at n-eos.com (Stephen Morris)
Date: Mon, 16 Sep 2019 06:43:05 +0000
Subject: [CMake] Preventing multiple definitions of metaObject methods
In-Reply-To: <1568390014.16243.17.camel@kitware.com>
References: <VE1PR06MB6350074C36E89AF2A4A35BE1C9B30@VE1PR06MB6350.eurprd06.prod.outlook.com>
 <1568390014.16243.17.camel@kitware.com>
Message-ID: <VE1PR06MB635071D791AFA5AEACEA448FC98C0@VE1PR06MB6350.eurprd06.prod.outlook.com>

-----Original Message-----
From: Kyle Edwards <kyle.edwards at kitware.com> 
Sent: 13 September 2019 16:54
To: Stephen Morris <s-morris at n-eos.com>; cmake at cmake.org
Subject: Re: [CMake] Preventing multiple definitions of metaObject methods

>Stephen,
>Could you post a minimally reproducible example with CMakeLists.txt and accompanying source code? I am currently working on a Qt-based >project with static libraries and have not encountered this issue.
>Kyle

Thank you Kyle. I created a basic example as you suggested - a simple application linking a simple static library, both incorporating a header containing Q_OBJECT - and to my great chagrin it worked perfectly, without any compilation errors. 

So it seems that I've been wrong to suspect this as the cause of the multiple-definition errors in my main project. Clearly I must dig deeper, and if I find that the final explanation is of general interest then I shall report back.

Stephen.

From s-morris at n-eos.com  Mon Sep 16 06:56:47 2019
From: s-morris at n-eos.com (Stephen Morris)
Date: Mon, 16 Sep 2019 10:56:47 +0000
Subject: [CMake] Preventing multiple definitions of metaObject methods
In-Reply-To: <VE1PR06MB635071D791AFA5AEACEA448FC98C0@VE1PR06MB6350.eurprd06.prod.outlook.com>
References: <VE1PR06MB6350074C36E89AF2A4A35BE1C9B30@VE1PR06MB6350.eurprd06.prod.outlook.com>
 <1568390014.16243.17.camel@kitware.com>
 <VE1PR06MB635071D791AFA5AEACEA448FC98C0@VE1PR06MB6350.eurprd06.prod.outlook.com>
Message-ID: <VE1PR06MB6350B1A01342170E13712E91C98C0@VE1PR06MB6350.eurprd06.prod.outlook.com>

-----Original Message-----
From: Kyle Edwards <kyle.edwards at kitware.com> 
Sent: 13 September 2019 16:54
To: Stephen Morris <s-morris at n-eos.com>; cmake at cmake.org
Subject: Re: [CMake] Preventing multiple definitions of metaObject methods

>Stephen,
>Could you post a minimally reproducible example with CMakeLists.txt and accompanying source code? I am currently working on a Qt-based >project with static libraries and have not encountered this issue.
>Kyle

It appears that the problem was due to a misunderstanding about how the PRIVATE keyword works in tergat_sources. I'd assumed that it should be used to identify the 'public headers' of a library (i.e. headers that should be included by the consumers of that library. It seems that this isn't the case, and even 'public' headers should be defined with the PRIVATE keyword.

Here are the simple demonstration files I wrote, four in all:

==== myTest.h ====

#ifndef MYTEST_HDR
#define MYTEST_HDR

class myTestWindow : public QMainWindow
{
    Q_OBJECT
public:
    myTestWindow()
    virtual ~myTestWindow();

signals:
    void readyToDisplay();

private slots:
    void showTitle();
};

#endif

==== myTest.cpp ====

#include <QtCore>
#include <QtWidgets>
#include "myTest.h"

myTestWindow::myTestWindow() : QMainWindow(nullptr)
{
    // Send the signal when ready to display
    (QTimer::singleShot(0, this, &myTestWindow::showTitle));
}

myTestWindow::~myTestWindow()
{}

void myTestWindow::showTitle()
{
    setWindowTitle(tr("This is a test window"));
}

#include "moc_myTest.cpp"

==== main.cpp ====

#include <QtCore>
#include <QtWidgets>

#include "myTest.h"

int main(int argc, char *argv[])
{
    QApplication * app = new QApplication (argc, argv);
    myTestWindow * win = new myTestWindow();
    win->show();
    app->exec();
    return 0;
}

==== CMakeLists.txt ====

cmake_minimum_required (VERSION 3.14)
project(myTest LANGUAGES CXX)

find_package(Qt5 COMPONENTS Core Gui Widgets REQUIRED PATHS "C:\\Qt\\5.12.3\\msvc2017_64\\lib\\cmake\\Qt5" NO_DEFAULT_PATH)
set (CMAKE_AUTOMOC ON)
set (CMAKE_AUTORCC ON)
set (CMAKE_AUTOUIC ON)

add_library(myTest_Lib STATIC)
target_sources(myTest_Lib PRIVATE myTest.cpp)
target_sources(myTest_Lib PUBLIC myTest.h)
target_link_libraries(myTest_Lib PUBLIC Qt5::Core Qt5::Widgets)
set_target_properties(myTest_Lib PROPERTIES OUTPUT_NAME myTest)

add_executable(myTest_Exe main.cpp)
target_include_directories(myTest_Exe PRIVATE ${CMAKE_LIST_DIR})
target_link_libraries(myTest_Exe PRIVATE myTest_Lib)
set_target_properties(myTest_Exe PROPERTIES OUTPUT_NAME myTest VS_DEBUGGER_ENVIRONMENT  "PATH=C:\\Qt\\5.12.3\\msvc2017_64\\bin;%PATH%")	


Compiling and running them as given here, with the line "target_sources(myTest_Lib PUBLIC myTest.h)" in the MakeLists.txt file, my library compiles cleanly but I get an error saying "'QMainWindow': base class undefined" when trying to compile the executable application. This is because the compiler encounters the Q_OBJECT macro in myTest.h, generates a new moc_myTest.cpp, then because it can't see that the original moc_myTest.cpp was compiled within the library it includes it in its own mocs_compilation.cpp file. The error occurs when trying to compile this file, since moc_myTest.cpp does not include <QMainWindow> anywhere.

If I try to fix this by adding the line "#include <QtWidgets/QMainWindow>" just above the class declaration in myTest.h, then the error changes to a bunch of 'multiple definition' errors, as I reported in my original question on Friday.

However, if I just change  "target_sources(myTest_Lib PUBLIC myTest.h)" to  "target_sources(myTest_Lib PRIVATE myTest.h)", then all the problems go away; it doesn't even matter whether I leave the redundant '#include' in myTest.h, everything compiles cleanly either way.

It seems that the matter of static vs. shared libraries in my initial question was a red herring - in my previous work with shared libraries I haven't used either the PUBLIC or PRIVATE keywords, but merely supplied add_library with a list of undifferentiated source files. This problem turns out to have been entirely a matter of the use of the PUBLIC keyword. I have obviously been using it incorrectly, though this leads me to wonder what its purpose is, if not for this.  

From ashish.sadanandan at gmail.com  Mon Sep 16 12:11:54 2019
From: ashish.sadanandan at gmail.com (Ashish Sadanandan)
Date: Mon, 16 Sep 2019 10:11:54 -0600
Subject: [CMake] Packaging a directory with CPack RPM
In-Reply-To: <CAPASGLr-bBnHbfZMHQxq5vCTgMwxYYGKgZ2e2ioWiVUTjibamA@mail.gmail.com>
References: <CAN44U22Un21wbT0QWCQPim816YFn_sbTE4QTNit2njVnvxLC-Q@mail.gmail.com>
 <CAPASGLr-bBnHbfZMHQxq5vCTgMwxYYGKgZ2e2ioWiVUTjibamA@mail.gmail.com>
Message-ID: <CAN44U22wzNypDjO1hihbw00BmFc_jWHmkmoaTqxPQZNY4+Swmw@mail.gmail.com>

On Thu, Sep 12, 2019 at 4:57 AM Eric Noulard <eric.noulard at gmail.com> wrote:
>
>
>
> Le jeu. 12 sept. 2019 ? 02:27, Ashish Sadanandan <ashish.sadanandan at gmail.com> a ?crit :
>>
>> Hello,
>> I'm using CPack to create RPMs for an application. I have this working but the CPack step is quite slow. While investigating this, I noticed that all files in a directory I'm packaging, which contains a large number of small files, is being listed in the spec file.
>>
>> For instance, say I have
>>
>>     set(CPACK_PACKAGING_INSTALL_PREFIX /opt/myapp)
>>     install(DIRECTORY ${CMAKE_BINARY_DIR}/myapp/foo
>>             DESTINATION foo
>>             COMPONENT myapp
>>     )
>>
>> In the %files section I see
>>
>>     %files
>>     %dir /opt/myapp/foo
>>     " /opt/myapp/foo/file1"
>>     " /opt/myapp/foo/file2"
>>     ...
>>     " /opt/myapp/foo/file60000"
>>
>> If I were writing the spec file by hand, this entire section could be replaced by a single line
>>
>>     %files
>>     /opt/myapp/foo
>
>
> CPack has no idea that the list of files are coming from an installed *directory*, because CPack is not doing the install CMake is.
> Thus CPackRPM and other CPack generators collect all installed bits inside a given [temporary] prefix directory.
>
> Now may be you can tell CPack to ignore some of you installed files/directory by using: CPACK_RPM_USER_FILELIST
>  https://cmake.org/cmake/help/v3.15/cpack_gen/rpm.html#cpack_gen:CPack%20RPM%20Generator
>

Sorry, I should've mentioned in the original email that the files are
required, so ignoring is not what I want.

>
>>
>> RPM will package all files within the directory if you specify the directory under %files (http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html - the "The %dir Directive" section)
>> Is there an option to list just the directory instead of recursively listing all contained files within the directory?
>
>
> AFAIK, No there is not.
>
>
>> I'm not claiming this is the reason for CPack being slow, I came across this while investigating performance and if nothing else, this will result in a cleaner looking spec file.
>
>
> For performance sake you can try CPACK_RPM_USER_BINARY_SPECFILE, CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
> and handcraft your "user" spec file in order to see if it helps the packaging performance.
> and/or you can set CPACK_RPM_PACKAGE_DEBUG to 1 in order to get more timed traces of CPackRPM execution.
>

Thanks, this looks promising but I'm having trouble getting CPack to
use my custom spec file. This is what I've added to my CMakeLists.txt
so far (using cmake 3.6.3)

    # We're already using component install
    set(CPACK_RPM_COMPONENT_INSTALL ON)
    set(CPACK_RPM_TESTS_FILE_NAME
        "${CPACK_PACKAGE_NAME}-tests-${CPACK_PACKAGE_VERSION}-${CPACK_RPM_PACKAGE_RELEASE}.${CMAKE_SYSTEM_PROCESSOR}.rpm"
    )
    install(DIRECTORY ${CMAKE_BINARY_DIR}/tests
            DESTINATION tests
            COMPONENT tests
    )
    set(CPACK_RPM_TESTS_USER_BINARY_SPECFILE
        "${CMAKE_CURRENT_SOURCE_DIR}/tests.spec"
    )

But CPack is still generating a spec file for the tests RPM instead of
using my spec file. I've even tried using an absolute path to the spec
file but still the same behavior. What am I doing wrong?


>
> --
> Eric

Thanks so much for your help,
Ashish.

From eric.noulard at gmail.com  Mon Sep 16 14:01:11 2019
From: eric.noulard at gmail.com (Eric Noulard)
Date: Mon, 16 Sep 2019 20:01:11 +0200
Subject: [CMake] Packaging a directory with CPack RPM
In-Reply-To: <CAN44U22wzNypDjO1hihbw00BmFc_jWHmkmoaTqxPQZNY4+Swmw@mail.gmail.com>
References: <CAN44U22Un21wbT0QWCQPim816YFn_sbTE4QTNit2njVnvxLC-Q@mail.gmail.com>
 <CAPASGLr-bBnHbfZMHQxq5vCTgMwxYYGKgZ2e2ioWiVUTjibamA@mail.gmail.com>
 <CAN44U22wzNypDjO1hihbw00BmFc_jWHmkmoaTqxPQZNY4+Swmw@mail.gmail.com>
Message-ID: <CAPASGLpwd7Yx0j_bTo7EZM1KSriJNyaKmTo9FUb3eYg0Q1iwZg@mail.gmail.com>

Le lun. 16 sept. 2019 ? 18:12, Ashish Sadanandan <
ashish.sadanandan at gmail.com> a ?crit :

> On Thu, Sep 12, 2019 at 4:57 AM Eric Noulard <eric.noulard at gmail.com>
> wrote:
> >
> >
> >
> > Le jeu. 12 sept. 2019 ? 02:27, Ashish Sadanandan <
> ashish.sadanandan at gmail.com> a ?crit :
>
> >
> > Now may be you can tell CPack to ignore some of you installed
> files/directory by using: CPACK_RPM_USER_FILELIST
> >
> https://cmake.org/cmake/help/v3.15/cpack_gen/rpm.html#cpack_gen:CPack%20RPM%20Generator
> >
>
> Sorry, I should've mentioned in the original email that the files are
> required, so ignoring is not what I want.
>

My answer wasn't clear, using   CPACK_RPM_USER_FILELIST enables you to
specify the de %file and/or %dir
directive you want and it thus make CPackRPM avoid using its ownn generated
file list  (i.e. ignore it).

You can somehow override the builtin file and dir discovery of CPack.

As the doc says:
"Since the CPack RPM generator is generating the list of files (and
directories) the user specified files of the
CPACK_RPM_<COMPONENT>_USER_FILELIST list will be removed from the generated
list. If referring to directories do not add a trailing slash."

>> I'm not claiming this is the reason for CPack being slow, I came across
> this while investigating performance and if nothing else, this will result
> in a cleaner looking spec file.
> >
> >
> > For performance sake you can try CPACK_RPM_USER_BINARY_SPECFILE,
> CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
> > and handcraft your "user" spec file in order to see if it helps the
> packaging performance.
> > and/or you can set CPACK_RPM_PACKAGE_DEBUG to 1 in order to get more
> timed traces of CPackRPM execution.
> >
>
> Thanks, this looks promising but I'm having trouble getting CPack to
> use my custom spec file. This is what I've added to my CMakeLists.txt
> so far (using cmake 3.6.3)
>


Then be sure to read the corresponding documentation:
https://cmake.org/cmake/help/v3.6/module/CPackRPM.html



>     # We're already using component install
>     set(CPACK_RPM_COMPONENT_INSTALL ON)
>     set(CPACK_RPM_TESTS_FILE_NAME
>
> "${CPACK_PACKAGE_NAME}-tests-${CPACK_PACKAGE_VERSION}-${CPACK_RPM_PACKAGE_RELEASE}.${CMAKE_SYSTEM_PROCESSOR}.rpm"
>     )
>     install(DIRECTORY ${CMAKE_BINARY_DIR}/tests
>             DESTINATION tests
>             COMPONENT tests
>     )
>     set(CPACK_RPM_TESTS_USER_BINARY_SPECFILE
>         "${CMAKE_CURRENT_SOURCE_DIR}/tests.spec"
>     )
>
> But CPack is still generating a spec file for the tests RPM instead of
> using my spec file. I've even tried using an absolute path to the spec
> file but still the same behavior. What am I doing wrong?
>

Difficult to say without seeing your CMakeLists.txt or verbose CPack output.

Did you set those variables before or after include(CPack) ?
Those vars should be set *before*  include(CPack) otherwise they won't be
taken into account.

Did you try running CPack in debug mode:

cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM

in order to have more verbose output?
-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190916/36b650cc/attachment.html>

From jp_abreu at id.uff.br  Mon Sep 16 16:32:25 2019
From: jp_abreu at id.uff.br (Joao Pedro Abreu De Souza)
Date: Mon, 16 Sep 2019 17:32:25 -0300
Subject: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86
Message-ID: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>

Hi guys. I am trying to generate,using cmake, a executable with target
Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
file (I find to Linux, to Android, but can't find to Windows 32 bits) to
build. Do you know some repository of toolchain files that has Windows 32
bits from Windows 64 bits? Or maybe someone has a standard toolchain file
to this type of thing.

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190916/2f1910f6/attachment.html>

From sancelot at numalliance.com  Tue Sep 17 02:26:28 2019
From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=)
Date: Tue, 17 Sep 2019 08:26:28 +0200
Subject: [CMake] toolchain file - cross-compiling
 windows-amd64->windows-x86
In-Reply-To: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
Message-ID: <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>

Hi,

That first depends on which compiler you will use ?

Regards,

S.Ancelot

Le 16/09/2019 ? 22:32, Joao Pedro Abreu De Souza a ?crit?:
> Hi guys. I am trying to generate,using cmake, a executable with target 
> Windows 32 bits using Windows 64 bits, but cannot find a standard 
> toolchain file (I find to Linux, to Android, but can't find to Windows 
> 32 bits) to build. Do you know some repository of toolchain files that 
> has Windows 32 bits from Windows 64 bits? Or maybe someone has a 
> standard toolchain file to this type of thing.
>
> Thanks in advance.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190917/7d643ea1/attachment.html>

From miroslav.ilias at umb.sk  Tue Sep 17 06:46:04 2019
From: miroslav.ilias at umb.sk (Ilias Miroslav, doc. RNDr., PhD.)
Date: Tue, 17 Sep 2019 10:46:04 +0000
Subject: [CMake] system runtime library file does not exist (warning)
Message-ID: <VI1PR07MB53923586E1A14A56C320ACA2F78F0@VI1PR07MB5392.eurprd07.prod.outlook.com>

Hello,

I have recent CMake 3.15.2 and old MKL library 11.1.

Upon configuration cmake is issuing warnings due to faulty determined folder of general name  FOLDER_lin (proper name is without lin):

CMake Warning at /home/milias/bin/cmake/cmake-3.15.2-Linux-x86_64/share/cmake-3.15/Modules/InstallRequiredSystemLibraries.cmake:684 (message):
  system runtime library file does not exist:
  '/mnt/apps/intel/composer_xe_2013_sp1.1.106/compiler/lib/intel64_lin/irml'
Call Stack (most recent call first):
  cmake/custom/cpack-dirac.cmake:1 (include)
  CMakeLists.txt:85 (include)

while proper MKL folder is:

ls /mnt/apps/intel/composer_xe_2013_sp1.1.106/compiler/lib/intel64/
cilk_db.so*     libcilkrts.so.5*        libcomposerxe_rdmgr_2.1.so*  libimf.so*      libistrconv.so*
codecov_libFNP.so*  libcomposerxe_boost_date_time_1.34.so*   libdecimal.a*    libintlc.so*      libmatmul.a*
crt/      libcomposerxe_boost_filesystem_1.34.so*  libicaf.so*    libintlc.so.5*     liboffload.so*
for_main.o*     libcomposerxe_boost_regex_1.34.so*      libifcore.a*    libiomp5.a*      liboffload.so.5*
icc_libFNP.so*     libcomposerxe_boost_system_1.34.so*      libifcore.so*    libiomp5.dbg*      libomp_db.so*
icpc_libFNP.so*     libcomposerxe_boost_thread_1.34.so*      libifcore.so.5*    libiomp5.so*      libpdbx.a*
ifort_libFNP.so*    libcomposerxe_cfgmgr_2.4.so*      libifcore_pic.a*    libiompstubs5.a*   libpdbx.so*
init.o*      libcomposerxe_clpt_3.1.so*       libifcoremt.a*    libiompstubs5.so*  libpdbx.so.5*
irml/      libcomposerxe_cpil_2.10.so*       libifcoremt.so*    libipgo.a*      libpdbxinst.a*
libbfp754.a*     libcomposerxe_gen_helpers_core_2.3.so*   libifcoremt.so.5*    libirc.a*      libsvml.a*
libchkp.so*     libcomposerxe_gen_helpers_das_2.3.so*    libifcoremt_pic.a    libirc.so*      libsvml.so*
libchkpwrap.a*     libcomposerxe_libxml_2.7.so*      libifport.a*    libirc_s.a*      locale/
libchkpwrap_w.a*    libcomposerxe_msngr_cmd_2.4.so*      libifport.so*    libirng.a*      ofldbegin.o*
libcilkrts.a*     libcomposerxe_msngr_reader_2.4.so*      libifport.so.5*    libirng.so*      ofldend.o
libcilkrts.so*     libcomposerxe_msngr_util_2.4.so*      libimf.a*     libistrconv.a*     tselect_libFNP.so*

This is only warning, maybe InstallRequiredSystemLibraries.cmake could be updated for that.

Best,

Miro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190917/f8cff3a5/attachment-0001.html>

From jp_abreu at id.uff.br  Tue Sep 17 08:17:50 2019
From: jp_abreu at id.uff.br (Joao Pedro Abreu De Souza)
Date: Tue, 17 Sep 2019 09:17:50 -0300
Subject: [CMake] toolchain file - cross-compiling
 windows-amd64->windows-x86
In-Reply-To: <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
 <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
Message-ID: <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>

cl from visual studio 2017.

Em ter, 17 de set de 2019 03:26, St?phane Ancelot <sancelot at numalliance.com>
escreveu:

> Hi,
>
> That first depends on which compiler you will use ?
>
> Regards,
>
> S.Ancelot
> Le 16/09/2019 ? 22:32, Joao Pedro Abreu De Souza a ?crit :
>
> Hi guys. I am trying to generate,using cmake, a executable with target
> Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
> build. Do you know some repository of toolchain files that has Windows 32
> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
> to this type of thing.
>
> Thanks in advance.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190917/27993e9a/attachment.html>

From AlbrechtS.fltk at online.de  Tue Sep 17 11:23:59 2019
From: AlbrechtS.fltk at online.de (Albrecht Schlosser)
Date: Tue, 17 Sep 2019 17:23:59 +0200
Subject: [CMake] toolchain file - cross-compiling
 windows-amd64->windows-x86
In-Reply-To: <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
 <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
 <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
Message-ID: <c3d6911e-8661-62cf-cc24-c9628d6a5173@online.de>

On 9/17/19 2:17 PM Joao Pedro Abreu De Souza wrote:
> cl from visual studio 2017.
> 
> Em ter, 17 de set de 2019 03:26, St?phane Ancelot 
> <sancelot at numalliance.com <mailto:sancelot at numalliance.com>> escreveu:
> 
>     Hi,
> 
>     That first depends on which compiler you will use ?
> 
>     Regards,
> 
>     S.Ancelot
> 
>     Le 16/09/2019 ? 22:32, Joao Pedro Abreu De Souza a ?crit?:
>>     Hi guys. I am trying to generate,using cmake, a executable with
>>     target Windows 32 bits using Windows 64 bits, but cannot find a
>>     standard toolchain file (I find to Linux, to Android, but can't
>>     find to Windows 32 bits) to build. Do you know some repository of
>>     toolchain files that has Windows 32 bits from Windows 64 bits? Or
>>     maybe someone has a standard toolchain file to this type of thing.

Well, I don't have a toolchain file for your compiler, but maybe my 
toolchain file for cross compilation under Linux for Windows (64-bit) 
can help. You'll need to adjust compiler and paths...

$ cat mingw-w64_toolchain.cmake
# CMake Toolchain File for MinGW-w64 (64-bit) Cross Compilation

# the name of the target operating system
set(CMAKE_SYSTEM_NAME Windows)

# which tools to use
set(CMAKE_C_COMPILER   /usr/bin/x86_64-w64-mingw32-gcc)
set(CMAKE_CXX_COMPILER /usr/bin/x86_64-w64-mingw32-g++)

# here is where the target environment located
set(CMAKE_FIND_ROOT_PATH  /usr/x86_64-w64-mingw32)

# adjust the default behavior of the FIND_XXX() commands:

# search programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

# search headers and libraries in the target environment
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

set(CMAKE_INSTALL_PREFIX ${CMAKE_FIND_ROOT_PATH}/usr CACHE FILEPATH
    "install path prefix")

# initialize required linker flags
set(CMAKE_EXE_LINKER_FLAGS_INIT "-static-libgcc -static-libstdc++")

# end of toolchain file

HTH. YMMV

From juan.e.sanchez at gmail.com  Tue Sep 17 12:21:08 2019
From: juan.e.sanchez at gmail.com (Juan Sanchez)
Date: Tue, 17 Sep 2019 11:21:08 -0500
Subject: [CMake] system runtime library file does not exist (warning)
In-Reply-To: <VI1PR07MB53923586E1A14A56C320ACA2F78F0@VI1PR07MB5392.eurprd07.prod.outlook.com>
References: <VI1PR07MB53923586E1A14A56C320ACA2F78F0@VI1PR07MB5392.eurprd07.prod.outlook.com>
Message-ID: <CAEHOsR1eeEgA7NPG4rL74YDHhEYbYjSLFUSk_=TY0DZiKQckqg@mail.gmail.com>

Hello,

Somewhat related to your issue, is that newer versions of the Intel MKL are
now free for use:
https://software.intel.com/en-us/articles/free-ipsxe-tools-and-libraries

Free Intel Performance Libraries
<https://software.intel.com/en-us/performance-libraries> for *Everyone*

*Free for all, no royalties, no restrictions on company or project size,
access to current & older versions of libraries (only current version for
Intel? MPI), Forum Support.*

Regards,

Juan

On Tue, Sep 17, 2019 at 5:46 AM Ilias Miroslav, doc. RNDr., PhD. <
miroslav.ilias at umb.sk> wrote:

> Hello,
>
> I have recent CMake 3.15.2 and old MKL library 11.1.
>
> Upon configuration cmake is issuing warnings due to faulty determined
> folder of general name  FOLDER_lin (proper name is without lin):
>
> CMake Warning at
> /home/milias/bin/cmake/cmake-3.15.2-Linux-x86_64/share/cmake-3.15/Modules/InstallRequiredSystemLibraries.cmake:684
> (message):
>   system runtime library file does not exist:
>   '/mnt/apps/intel/composer_xe_2013_sp1.1.106/compiler/lib/intel64*_lin*
> /irml'
> Call Stack (most recent call first):
>   cmake/custom/cpack-dirac.cmake:1 (include)
>   CMakeLists.txt:85 (include)
>
> while proper MKL folder is:
>
> ls /mnt/apps/intel/composer_xe_2013_sp1.1.106/compiler/lib/intel64/
> cilk_db.so*     libcilkrts.so.5*        libcomposerxe_rdmgr_2.1.so*
>  libimf.so*      libistrconv.so*
> codecov_libFNP.so*  libcomposerxe_boost_date_time_1.34.so*
> libdecimal.a*    libintlc.so*      libmatmul.a*
> crt/      libcomposerxe_boost_filesystem_1.34.so*  libicaf.so*
>  libintlc.so.5*     liboffload.so*
> for_main.o*     libcomposerxe_boost_regex_1.34.so*      libifcore.a*
>  libiomp5.a*      liboffload.so.5*
> icc_libFNP.so*     libcomposerxe_boost_system_1.34.so*      libifcore.so*
>    libiomp5.dbg*      libomp_db.so*
> icpc_libFNP.so*     libcomposerxe_boost_thread_1.34.so*
>  libifcore.so.5*    libiomp5.so*      libpdbx.a*
> ifort_libFNP.so*    libcomposerxe_cfgmgr_2.4.so*      libifcore_pic.a*
>  libiompstubs5.a*   libpdbx.so*
> init.o*      libcomposerxe_clpt_3.1.so*       libifcoremt.a*
>  libiompstubs5.so*  libpdbx.so.5*
> irml/      libcomposerxe_cpil_2.10.so*       libifcoremt.so*
>  libipgo.a*      libpdbxinst.a*
> libbfp754.a*     libcomposerxe_gen_helpers_core_2.3.so*
> libifcoremt.so.5*    libirc.a*      libsvml.a*
> libchkp.so*     libcomposerxe_gen_helpers_das_2.3.so*
>  libifcoremt_pic.a    libirc.so*      libsvml.so*
> libchkpwrap.a*     libcomposerxe_libxml_2.7.so*      libifport.a*
>  libirc_s.a*      locale/
> libchkpwrap_w.a*    libcomposerxe_msngr_cmd_2.4.so*      libifport.so*
>  libirng.a*      ofldbegin.o*
> libcilkrts.a*     libcomposerxe_msngr_reader_2.4.so*      libifport.so.5*
>    libirng.so*      ofldend.o
> libcilkrts.so*     libcomposerxe_msngr_util_2.4.so*      libimf.a*
> libistrconv.a*     tselect_libFNP.so*
>
> This is only warning, maybe InstallRequiredSystemLibraries.cmake could be
> updated for that.
>
> Best,
>
> Miro
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190917/e001e3c3/attachment.html>

From juan.e.sanchez at gmail.com  Tue Sep 17 13:00:18 2019
From: juan.e.sanchez at gmail.com (Juan Sanchez)
Date: Tue, 17 Sep 2019 12:00:18 -0500
Subject: [CMake] toolchain file - cross-compiling
 windows-amd64->windows-x86
In-Reply-To: <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
 <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
 <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
Message-ID: <CAEHOsR3gjhs5gwKrBsVxYu1F-m+brzZU7JBvQDiGsVmk2Nq2qw@mail.gmail.com>

Hello,

My impression that targeting 32 bit depends on what generator you are using.
https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html

It looks like cmake now has:

   - cmake -G "Visual Studio 15 2017" -A Win32
   - cmake -G "Visual Studio 15 2017" -A x64

It used to be that the default target platform was Win32, and  you had to
specify Win64 in the generator string to target a 64 bit build.  For
example with Visual Studio 2015

https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html

For compatibility with CMake versions prior to 3.1, one may specify a
target platform name optionally at the end of the generator name. This is
supported only for:
Visual Studio 14 2015 Win64Specify target platform x64.Visual Studio 14 2015
 ARMSpecify target platform ARM.


Regards,

Juan


On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <
jp_abreu at id.uff.br> wrote:

> cl from visual studio 2017.
>
> Em ter, 17 de set de 2019 03:26, St?phane Ancelot <
> sancelot at numalliance.com> escreveu:
>
>> Hi,
>>
>> That first depends on which compiler you will use ?
>>
>> Regards,
>>
>> S.Ancelot
>> Le 16/09/2019 ? 22:32, Joao Pedro Abreu De Souza a ?crit :
>>
>> Hi guys. I am trying to generate,using cmake, a executable with target
>> Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
>> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
>> build. Do you know some repository of toolchain files that has Windows 32
>> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
>> to this type of thing.
>>
>> Thanks in advance.
>>
>> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190917/85c677a9/attachment.html>

From guymac at gmail.com  Tue Sep 17 14:09:38 2019
From: guymac at gmail.com (Guy Mac)
Date: Tue, 17 Sep 2019 11:09:38 -0700
Subject: [CMake] toolchain file - cross-compiling
 windows-amd64->windows-x86
In-Reply-To: <CAEHOsR3gjhs5gwKrBsVxYu1F-m+brzZU7JBvQDiGsVmk2Nq2qw@mail.gmail.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
 <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
 <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
 <CAEHOsR3gjhs5gwKrBsVxYu1F-m+brzZU7JBvQDiGsVmk2Nq2qw@mail.gmail.com>
Message-ID: <97f6d937-c921-f9af-5535-6f06db173038@gmail.com>

AFAIK you can set the generator in a CMakeSettings.json file if you are 
using MSVC.

https://docs.microsoft.com/en-us/cpp/build/cmakesettings-reference?view=vs-2019

On 9/17/2019 10:00 AM, Juan Sanchez wrote:
> Hello,
>
> My impression that targeting 32 bit depends on what generator you are 
> using.
> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
>
> It looks like cmake now has:
>
>   * |cmake -G "Visual Studio 15 2017" -A Win32|
>   * |cmake -G "Visual Studio 15 2017" -A x64|
>
> It used to be that the default target platform was Win32, and? you had 
> to specify Win64 in the generator string to target a 64 bit build.? 
> For example with Visual Studio 2015
>
> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
>
> For compatibility with CMake versions prior to 3.1, one may specify a 
> target platform name optionally at the end of the generator name. This 
> is supported only for:
>
> |Visual Studio 14 2015 Win64|
>     Specify target platform |x64|.
> |Visual Studio 14 2015 ARM|
>     Specify target platform |ARM|.
>
>
>
> Regards,
>
> Juan
>
>
> On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza 
> <jp_abreu at id.uff.br <mailto:jp_abreu at id.uff.br>> wrote:
>
>     cl from visual studio 2017.
>
>     Em ter, 17 de set de 2019 03:26, St?phane Ancelot
>     <sancelot at numalliance.com <mailto:sancelot at numalliance.com>> escreveu:
>
>         Hi,
>
>         That first depends on which compiler you will use ?
>
>         Regards,
>
>         S.Ancelot
>
>         Le 16/09/2019 ? 22:32, Joao Pedro Abreu De Souza a ?crit?:
>>         Hi guys. I am trying to generate,using cmake, a executable
>>         with target Windows 32 bits using Windows 64 bits, but cannot
>>         find a standard toolchain file (I find to Linux, to Android,
>>         but can't find to Windows 32 bits) to build. Do you know some
>>         repository of toolchain files that has Windows 32 bits from
>>         Windows 64 bits? Or maybe someone has a standard toolchain
>>         file to this type of thing.
>>
>>         Thanks in advance.
>>
>     -- 
>
>     Powered by www.kitware.com <http://www.kitware.com>
>
>     Please keep messages on-topic and check the CMake FAQ at:
>     http://www.cmake.org/Wiki/CMake_FAQ
>
>     Kitware offers various services to support the CMake community.
>     For more information on each offering, please visit:
>
>     CMake Support: http://cmake.org/cmake/help/support.html
>     CMake Consulting: http://cmake.org/cmake/help/consulting.html
>     CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>     Visit other Kitware open-source projects at
>     http://www.kitware.com/opensource/opensource.html
>
>     Follow this link to subscribe/unsubscribe:
>     https://cmake.org/mailman/listinfo/cmake
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190917/7b53fefb/attachment-0001.html>

From jp_abreu at id.uff.br  Tue Sep 17 14:36:22 2019
From: jp_abreu at id.uff.br (Joao Pedro Abreu De Souza)
Date: Tue, 17 Sep 2019 15:36:22 -0300
Subject: [CMake] toolchain file - cross-compiling
 windows-amd64->windows-x86
In-Reply-To: <CAEHOsR3gjhs5gwKrBsVxYu1F-m+brzZU7JBvQDiGsVmk2Nq2qw@mail.gmail.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
 <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
 <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
 <CAEHOsR3gjhs5gwKrBsVxYu1F-m+brzZU7JBvQDiGsVmk2Nq2qw@mail.gmail.com>
Message-ID: <CAB57kXpqq3EJrAmm0DnkOx5VMwWUVt9s3Gicc-8SL-upzpiPWA@mail.gmail.com>

So, only the Visual Studio generator use the Arch option? I try generate
ninja build, but cmake(3.15.3) and the answer was

```
$ cmake -B build -S . -G "Ninja" -A Win32
CMake Error at CMakeLists.txt:2 (project):
  Generator

    Ninja

  does not support platform specification, but platform

    Win32

  was specified.


CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
See also
"C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
```

Em ter, 17 de set de 2019 ?s 14:00, Juan Sanchez <juan.e.sanchez at gmail.com>
escreveu:

> Hello,
>
> My impression that targeting 32 bit depends on what generator you are
> using.
>
> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
>
> It looks like cmake now has:
>
>    - cmake -G "Visual Studio 15 2017" -A Win32
>    - cmake -G "Visual Studio 15 2017" -A x64
>
> It used to be that the default target platform was Win32, and  you had to
> specify Win64 in the generator string to target a 64 bit build.  For
> example with Visual Studio 2015
>
>
> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
>
> For compatibility with CMake versions prior to 3.1, one may specify a
> target platform name optionally at the end of the generator name. This is
> supported only for:
> Visual Studio 14 2015 Win64Specify target platform x64.Visual Studio 14
> 2015 ARMSpecify target platform ARM.
>
>
> Regards,
>
> Juan
>
>
> On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <
> jp_abreu at id.uff.br> wrote:
>
>> cl from visual studio 2017.
>>
>> Em ter, 17 de set de 2019 03:26, St?phane Ancelot <
>> sancelot at numalliance.com> escreveu:
>>
>>> Hi,
>>>
>>> That first depends on which compiler you will use ?
>>>
>>> Regards,
>>>
>>> S.Ancelot
>>> Le 16/09/2019 ? 22:32, Joao Pedro Abreu De Souza a ?crit :
>>>
>>> Hi guys. I am trying to generate,using cmake, a executable with target
>>> Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
>>> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
>>> build. Do you know some repository of toolchain files that has Windows 32
>>> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
>>> to this type of thing.
>>>
>>> Thanks in advance.
>>>
>>> --
>>
>> 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 services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190917/e332a613/attachment.html>

From juan.e.sanchez at gmail.com  Tue Sep 17 15:01:25 2019
From: juan.e.sanchez at gmail.com (Juan Sanchez)
Date: Tue, 17 Sep 2019 14:01:25 -0500
Subject: [CMake] toolchain file - cross-compiling
 windows-amd64->windows-x86
In-Reply-To: <CAB57kXpqq3EJrAmm0DnkOx5VMwWUVt9s3Gicc-8SL-upzpiPWA@mail.gmail.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
 <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
 <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
 <CAEHOsR3gjhs5gwKrBsVxYu1F-m+brzZU7JBvQDiGsVmk2Nq2qw@mail.gmail.com>
 <CAB57kXpqq3EJrAmm0DnkOx5VMwWUVt9s3Gicc-8SL-upzpiPWA@mail.gmail.com>
Message-ID: <CAEHOsR1p_ysZB1jO=e3zzeTfM4Xx9_=GO5e9_ZcfPmWXQEKwDg@mail.gmail.com>

>From my brief research, it looks like the Microsoft version of CMake may
have Ninja support.

https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/


Regards,

Juan

On Tue, Sep 17, 2019 at 1:36 PM Joao Pedro Abreu De Souza <
jp_abreu at id.uff.br> wrote:

> So, only the Visual Studio generator use the Arch option? I try generate
> ninja build, but cmake(3.15.3) and the answer was
>
> ```
> $ cmake -B build -S . -G "Ninja" -A Win32
> CMake Error at CMakeLists.txt:2 (project):
>   Generator
>
>     Ninja
>
>   does not support platform specification, but platform
>
>     Win32
>
>   was specified.
>
>
> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
> -- Configuring incomplete, errors occurred!
> See also
> "C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
> ```
>
> Em ter, 17 de set de 2019 ?s 14:00, Juan Sanchez <juan.e.sanchez at gmail.com>
> escreveu:
>
>> Hello,
>>
>> My impression that targeting 32 bit depends on what generator you are
>> using.
>>
>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
>>
>> It looks like cmake now has:
>>
>>    - cmake -G "Visual Studio 15 2017" -A Win32
>>    - cmake -G "Visual Studio 15 2017" -A x64
>>
>> It used to be that the default target platform was Win32, and  you had to
>> specify Win64 in the generator string to target a 64 bit build.  For
>> example with Visual Studio 2015
>>
>>
>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
>>
>> For compatibility with CMake versions prior to 3.1, one may specify a
>> target platform name optionally at the end of the generator name. This is
>> supported only for:
>> Visual Studio 14 2015 Win64Specify target platform x64.Visual Studio 14
>> 2015 ARMSpecify target platform ARM.
>>
>>
>> Regards,
>>
>> Juan
>>
>>
>> On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <
>> jp_abreu at id.uff.br> wrote:
>>
>>> cl from visual studio 2017.
>>>
>>> Em ter, 17 de set de 2019 03:26, St?phane Ancelot <
>>> sancelot at numalliance.com> escreveu:
>>>
>>>> Hi,
>>>>
>>>> That first depends on which compiler you will use ?
>>>>
>>>> Regards,
>>>>
>>>> S.Ancelot
>>>> Le 16/09/2019 ? 22:32, Joao Pedro Abreu De Souza a ?crit :
>>>>
>>>> Hi guys. I am trying to generate,using cmake, a executable with target
>>>> Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
>>>> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
>>>> build. Do you know some repository of toolchain files that has Windows 32
>>>> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
>>>> to this type of thing.
>>>>
>>>> Thanks in advance.
>>>>
>>>> --
>>>
>>> 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 services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://cmake.org/mailman/listinfo/cmake
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190917/0a3e9fec/attachment-0001.html>

From jp_abreu at id.uff.br  Tue Sep 17 15:11:48 2019
From: jp_abreu at id.uff.br (Joao Pedro Abreu De Souza)
Date: Tue, 17 Sep 2019 16:11:48 -0300
Subject: [CMake] toolchain file - cross-compiling
 windows-amd64->windows-x86
In-Reply-To: <CAEHOsR1p_ysZB1jO=e3zzeTfM4Xx9_=GO5e9_ZcfPmWXQEKwDg@mail.gmail.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
 <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
 <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
 <CAEHOsR3gjhs5gwKrBsVxYu1F-m+brzZU7JBvQDiGsVmk2Nq2qw@mail.gmail.com>
 <CAB57kXpqq3EJrAmm0DnkOx5VMwWUVt9s3Gicc-8SL-upzpiPWA@mail.gmail.com>
 <CAEHOsR1p_ysZB1jO=e3zzeTfM4Xx9_=GO5e9_ZcfPmWXQEKwDg@mail.gmail.com>
Message-ID: <CAB57kXpvQj6x4drQxxq90h0dWTzvsHgN0YvPoVTFyJuqF-gL5Q@mail.gmail.com>

Thanks, I'll check it out.

The toolchain file, as is, can generate ninja builds that can be used to
generate a executable, but when I execute them, he say :

```
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/amd64_x86/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/amd64_x86/cl.exe -- broken
CMake Error at C:/Program
Files/CMake/share/cmake-3.15/Modules/CMakeTestCCompiler.cmake:60 (message):
  The C compiler

    "C:/Program Files (x86)/Microsoft Visual Studio
12.0/VC/bin/amd64_x86/cl.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir:
C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp

    Run Build Command(s):C:/ProgramData/chocolatey/bin/ninja.exe cmTC_0dfb4
&& [1/2] Building C object CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj
    FAILED: CMakeFiles/cmTC_0dfb4.dir/testCCompiler.c.obj
    "C:\PROGRA~2\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\cl.exe"
 -o CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj   -c testCCompiler.c
    ninja: build stopped: subcommand failed.





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)
```

Em ter, 17 de set de 2019 ?s 16:02, Juan Sanchez <juan.e.sanchez at gmail.com>
escreveu:

> From my brief research, it looks like the Microsoft version of CMake may
> have Ninja support.
>
>
> https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/
>
>
> Regards,
>
> Juan
>
> On Tue, Sep 17, 2019 at 1:36 PM Joao Pedro Abreu De Souza <
> jp_abreu at id.uff.br> wrote:
>
>> So, only the Visual Studio generator use the Arch option? I try generate
>> ninja build, but cmake(3.15.3) and the answer was
>>
>> ```
>> $ cmake -B build -S . -G "Ninja" -A Win32
>> CMake Error at CMakeLists.txt:2 (project):
>>   Generator
>>
>>     Ninja
>>
>>   does not support platform specification, but platform
>>
>>     Win32
>>
>>   was specified.
>>
>>
>> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
>> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
>> -- Configuring incomplete, errors occurred!
>> See also
>> "C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
>> ```
>>
>> Em ter, 17 de set de 2019 ?s 14:00, Juan Sanchez <
>> juan.e.sanchez at gmail.com> escreveu:
>>
>>> Hello,
>>>
>>> My impression that targeting 32 bit depends on what generator you are
>>> using.
>>>
>>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
>>>
>>> It looks like cmake now has:
>>>
>>>    - cmake -G "Visual Studio 15 2017" -A Win32
>>>    - cmake -G "Visual Studio 15 2017" -A x64
>>>
>>> It used to be that the default target platform was Win32, and  you had
>>> to specify Win64 in the generator string to target a 64 bit build.  For
>>> example with Visual Studio 2015
>>>
>>>
>>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
>>>
>>> For compatibility with CMake versions prior to 3.1, one may specify a
>>> target platform name optionally at the end of the generator name. This is
>>> supported only for:
>>> Visual Studio 14 2015 Win64Specify target platform x64.Visual Studio 14
>>> 2015 ARMSpecify target platform ARM.
>>>
>>>
>>> Regards,
>>>
>>> Juan
>>>
>>>
>>> On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <
>>> jp_abreu at id.uff.br> wrote:
>>>
>>>> cl from visual studio 2017.
>>>>
>>>> Em ter, 17 de set de 2019 03:26, St?phane Ancelot <
>>>> sancelot at numalliance.com> escreveu:
>>>>
>>>>> Hi,
>>>>>
>>>>> That first depends on which compiler you will use ?
>>>>>
>>>>> Regards,
>>>>>
>>>>> S.Ancelot
>>>>> Le 16/09/2019 ? 22:32, Joao Pedro Abreu De Souza a ?crit :
>>>>>
>>>>> Hi guys. I am trying to generate,using cmake, a executable with target
>>>>> Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
>>>>> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
>>>>> build. Do you know some repository of toolchain files that has Windows 32
>>>>> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
>>>>> to this type of thing.
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> --
>>>>
>>>> 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 services to support the CMake community. For
>>>> more information on each offering, please visit:
>>>>
>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> https://cmake.org/mailman/listinfo/cmake
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190917/4c9f7262/attachment.html>

From fdk17 at ftml.net  Tue Sep 17 15:46:28 2019
From: fdk17 at ftml.net (fdk17)
Date: Tue, 17 Sep 2019 15:46:28 -0400
Subject: [CMake] 
 =?utf-8?q?toolchain_file_-_cross-compiling_windows-amd64?=
 =?utf-8?q?-=3Ewindows-x86?=
In-Reply-To: <CAB57kXpvQj6x4drQxxq90h0dWTzvsHgN0YvPoVTFyJuqF-gL5Q@mail.gmail.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
 <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
 <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
 <CAEHOsR3gjhs5gwKrBsVxYu1F-m+brzZU7JBvQDiGsVmk2Nq2qw@mail.gmail.com>
 <CAB57kXpqq3EJrAmm0DnkOx5VMwWUVt9s3Gicc-8SL-upzpiPWA@mail.gmail.com>
 <CAEHOsR1p_ysZB1jO=e3zzeTfM4Xx9_=GO5e9_ZcfPmWXQEKwDg@mail.gmail.com>
 <CAB57kXpvQj6x4drQxxq90h0dWTzvsHgN0YvPoVTFyJuqF-gL5Q@mail.gmail.com>
Message-ID: <a30f8feb-798d-492a-933d-2ff89e8ed630@www.fastmail.com>

As I recall for myself, simply using the Visual Studio Generator with the -A option was all that was needed to build for Win32.
You don't need a toolchain file because the generator already knows how to setup a Visual Studio Project to target Win32.
Even the documentation for cross-compiling doesn't show a need to setup toolchain file for cross compiling in this case.

I personally never seen anyone try to use the Ninja generator via command line CMake and use the cl.exe compiler.
I've only seen that using Visual Studio to open a CMakeLists.txt file it can produce a Ninja project. But even MS documentation states that it doesn't always work.

https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
This says you should be able to open the proper development window and use Ninja.

The output shows that in the environment you are using it doesn't even know how to use cl.exe to even determine with compiler it is. Maybe not all the proper environment variables and paths are being set correctly when using the compiler.

--
F

On Tue, Sep 17, 2019, at 3:11 PM, Joao Pedro Abreu De Souza wrote:
> Thanks, I'll check it out.
> 
> The toolchain file, as is, can generate ninja builds that can be used to generate a executable, but when I execute them, he say : 
> 
> ```
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64_x86/cl.exe
> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64_x86/cl.exe -- broken
> CMake Error at C:/Program Files/CMake/share/cmake-3.15/Modules/CMakeTestCCompiler.cmake:60 (message):
>  The C compiler
> 
>  "C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64_x86/cl.exe"
> 
>  is not able to compile a simple test program.
> 
>  It fails with the following output:
> 
>  Change Dir: C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp
> 
>  Run Build Command(s):C:/ProgramData/chocolatey/bin/ninja.exe cmTC_0dfb4 && [1/2] Building C object CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj
>  FAILED: CMakeFiles/cmTC_0dfb4.dir/testCCompiler.c.obj
>  "C:\PROGRA~2\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\cl.exe" -o CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj -c testCCompiler.c
>  ninja: build stopped: subcommand failed.
> 
> 
> 
> 
> 
>  CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
>  CMakeLists.txt:2 (project)
> ```
> 
> Em ter, 17 de set de 2019 ?s 16:02, Juan Sanchez <juan.e.sanchez at gmail.com> escreveu:
>> From my brief research, it looks like the Microsoft version of CMake may have Ninja support.
>> 
>> https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/ 
>> 
>> Regards,
>> 
>> Juan
>> 
>> On Tue, Sep 17, 2019 at 1:36 PM Joao Pedro Abreu De Souza <jp_abreu at id.uff.br> wrote:
>>> So, only the Visual Studio generator use the Arch option? I try generate ninja build, but cmake(3.15.3) and the answer was 
>>> 
>>> ```
>>> $ cmake -B build -S . -G "Ninja" -A Win32
>>> CMake Error at CMakeLists.txt:2 (project):
>>>  Generator
>>> 
>>>  Ninja
>>> 
>>>  does not support platform specification, but platform
>>> 
>>>  Win32
>>> 
>>>  was specified.
>>> 
>>> 
>>> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
>>> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
>>> -- Configuring incomplete, errors occurred!
>>> See also "C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
>>> ```
>>> 
>>> Em ter, 17 de set de 2019 ?s 14:00, Juan Sanchez <juan.e.sanchez at gmail.com> escreveu:
>>>> Hello,
>>>> 
>>>> My impression that targeting 32 bit depends on what generator you are using.
>>>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
>>>> 
>>>> It looks like cmake now has:
>>>>  * `cmake -G "Visual Studio 15 2017" -A Win32`
>>>>  * `cmake -G "Visual Studio 15 2017" -A x64`
>>>> It used to be that the default target platform was Win32, and you had to specify Win64 in the generator string to target a 64 bit build. For example with Visual Studio 2015
>>>> 
>>>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
>>>> 
>>>> For compatibility with CMake versions prior to 3.1, one may specify a target platform name optionally at the end of the generator name. This is supported only for:

>>>> `Visual Studio 14 2015 Win64`
>>>> Specify target platform `x64`.
>>>> `Visual Studio 14 2015 ARM`
>>>> Specify target platform `ARM`.
>>>> 
>>>> 
>>>> Regards,
>>>> 
>>>> Juan
>>>> 
>>>> 
>>>> On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <jp_abreu at id.uff.br> wrote:
>>>>> cl from visual studio 2017.
>>>>> 
>>>>> Em ter, 17 de set de 2019 03:26, St?phane Ancelot <sancelot at numalliance.com> escreveu:
>>>>>> Hi,

>>>>>> That first depends on which compiler you will use ?

>>>>>> Regards,

>>>>>> S.Ancelot

>>>>>> Le 16/09/2019 ? 22:32, Joao Pedro Abreu De Souza a ?crit :
>>>>>>> Hi guys. I am trying to generate,using cmake, a executable with target Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain file (I find to Linux, to Android, but can't find to Windows 32 bits) to build. Do you know some repository of toolchain files that has Windows 32 bits from Windows 64 bits? Or maybe someone has a standard toolchain file to this type of thing. 
>>>>>>> 
>>>>>>> Thanks in advance.
>>>>>>> 
>>>>> --
>>>>> 
>>>>>  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 services to support the CMake community. For more information on each offering, please visit:
>>>>> 
>>>>>  CMake Support: http://cmake.org/cmake/help/support.html
>>>>>  CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>>>  CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>>> 
>>>>>  Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>> 
>>>>>  Follow this link to subscribe/unsubscribe:
>>>>> https://cmake.org/mailman/listinfo/cmake
> -- 
> 
> 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 services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190917/fd71a471/attachment-0001.html>

From jp_abreu at id.uff.br  Tue Sep 17 16:48:13 2019
From: jp_abreu at id.uff.br (Joao Pedro Abreu De Souza)
Date: Tue, 17 Sep 2019 17:48:13 -0300
Subject: [CMake] toolchain file - cross-compiling
 windows-amd64->windows-x86
In-Reply-To: <a30f8feb-798d-492a-933d-2ff89e8ed630@www.fastmail.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
 <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
 <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
 <CAEHOsR3gjhs5gwKrBsVxYu1F-m+brzZU7JBvQDiGsVmk2Nq2qw@mail.gmail.com>
 <CAB57kXpqq3EJrAmm0DnkOx5VMwWUVt9s3Gicc-8SL-upzpiPWA@mail.gmail.com>
 <CAEHOsR1p_ysZB1jO=e3zzeTfM4Xx9_=GO5e9_ZcfPmWXQEKwDg@mail.gmail.com>
 <CAB57kXpvQj6x4drQxxq90h0dWTzvsHgN0YvPoVTFyJuqF-gL5Q@mail.gmail.com>
 <a30f8feb-798d-492a-933d-2ff89e8ed630@www.fastmail.com>
Message-ID: <CAB57kXo2wsyYK-CghLHG5rnvjNLha0H_KegF=PiyJ7hjN4=mpg@mail.gmail.com>

Well, the Visual Studio Generator alone is not a option because the
repository has a actual build system(a bunch of bat files that call a
python script that generate ninja files).
We want to change to cmake, and now we don't use Visual Studio a lot. Most
of time, we only need their compiler and linker.

Well, Thanks all for the attention, sorry about the time wasted. I will
continue to search to exactly options and, in case of sucess, mail here
again.
Great day to all of you.

Em ter, 17 de set de 2019 ?s 16:56, fdk17 <fdk17 at ftml.net> escreveu:

> As I recall for myself, simply using the Visual Studio Generator with the
> -A option was all that was needed to build for Win32.
> You don't need a toolchain file because the generator already knows how to
> setup a Visual Studio Project to target Win32.
> Even the documentation for cross-compiling doesn't show a need to setup
> toolchain file for cross compiling in this case.
>
> I personally never seen anyone try to use the Ninja generator via command
> line CMake and use the cl.exe compiler.
> I've only seen that using Visual Studio to open a CMakeLists.txt file it
> can produce a Ninja project.  But even MS documentation states that it
> doesn't always work.
>
>
> https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
> This says you should be able to open the proper development window and use
> Ninja.
>
> The output shows that in the environment you are using it doesn't even
> know how to use cl.exe to even determine with compiler it is.  Maybe not
> all the proper environment variables and paths are being set correctly when
> using the compiler.
>
> --
> F
>
> On Tue, Sep 17, 2019, at 3:11 PM, Joao Pedro Abreu De Souza wrote:
>
> Thanks, I'll check it out.
>
> The toolchain file, as is, can generate ninja builds that can be used to
> generate a executable, but when I execute them, he say :
>
> ```
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
> Studio 12.0/VC/bin/amd64_x86/cl.exe
> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
> Studio 12.0/VC/bin/amd64_x86/cl.exe -- broken
> CMake Error at C:/Program
> Files/CMake/share/cmake-3.15/Modules/CMakeTestCCompiler.cmake:60 (message):
>   The C compiler
>
>     "C:/Program Files (x86)/Microsoft Visual Studio
> 12.0/VC/bin/amd64_x86/cl.exe"
>
>   is not able to compile a simple test program.
>
>   It fails with the following output:
>
>     Change Dir:
> C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp
>
>     Run Build Command(s):C:/ProgramData/chocolatey/bin/ninja.exe
> cmTC_0dfb4 && [1/2] Building C object
> CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj
>     FAILED: CMakeFiles/cmTC_0dfb4.dir/testCCompiler.c.obj
>     "C:\PROGRA~2\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\cl.exe"
>  -o CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj   -c testCCompiler.c
>     ninja: build stopped: subcommand failed.
>
>
>
>
>
>   CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
>   CMakeLists.txt:2 (project)
> ```
>
> Em ter, 17 de set de 2019 ?s 16:02, Juan Sanchez <juan.e.sanchez at gmail.com>
> escreveu:
>
> From my brief research, it looks like the Microsoft version of CMake may
> have Ninja support.
>
>
> https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/
>
>
> Regards,
>
> Juan
>
> On Tue, Sep 17, 2019 at 1:36 PM Joao Pedro Abreu De Souza <
> jp_abreu at id.uff.br> wrote:
>
> So, only the Visual Studio generator use the Arch option? I try generate
> ninja build, but cmake(3.15.3) and the answer was
>
> ```
> $ cmake -B build -S . -G "Ninja" -A Win32
> CMake Error at CMakeLists.txt:2 (project):
>   Generator
>
>     Ninja
>
>   does not support platform specification, but platform
>
>     Win32
>
>   was specified.
>
>
> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
> -- Configuring incomplete, errors occurred!
> See also
> "C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
> ```
>
> Em ter, 17 de set de 2019 ?s 14:00, Juan Sanchez <juan.e.sanchez at gmail.com>
> escreveu:
>
> Hello,
>
> My impression that targeting 32 bit depends on what generator you are
> using.
>
> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
>
> It looks like cmake now has:
>
>    - cmake -G "Visual Studio 15 2017" -A Win32
>    - cmake -G "Visual Studio 15 2017" -A x64
>
> It used to be that the default target platform was Win32, and  you had to
> specify Win64 in the generator string to target a 64 bit build.  For
> example with Visual Studio 2015
>
>
> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
>
> For compatibility with CMake versions prior to 3.1, one may specify a
> target platform name optionally at the end of the generator name. This is
> supported only for:
> Visual Studio 14 2015 Win64
> Specify target platform x64.
> Visual Studio 14 2015 ARM
> Specify target platform ARM.
>
>
> Regards,
>
> Juan
>
>
> On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <
> jp_abreu at id.uff.br> wrote:
>
> cl from visual studio 2017.
>
> Em ter, 17 de set de 2019 03:26, St?phane Ancelot <
> sancelot at numalliance.com> escreveu:
>
> Hi,
>
> That first depends on which compiler you will use ?
>
> Regards,
>
> S.Ancelot
> Le 16/09/2019 ? 22:32, Joao Pedro Abreu De Souza a ?crit :
>
> Hi guys. I am trying to generate,using cmake, a executable with target
> Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
> build. Do you know some repository of toolchain files that has Windows 32
> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
> to this type of thing.
>
> Thanks in advance.
>
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
>
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190917/5844da48/attachment.html>

From Alan.W.Irwin1234 at gmail.com  Tue Sep 17 19:21:36 2019
From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin)
Date: Tue, 17 Sep 2019 16:21:36 -0700 (PDT)
Subject: [CMake] Difference between PRIVATE and PUBLIC with
 target_link_libraries
In-Reply-To: <CA+dygY=342rwEpGn4btVZdqdBamGEBdBfQw0DaZsuTf_9L1JWw@mail.gmail.com>
References: <20160510075948.1f445585@posteo.de>
 <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com>
 <20160511071355.7209ed8a@vdr>
 <CAGyo1ox+D+Maa2QL8iDEx12cxNfU6DfpKLgaz5W-=Dk5R+WvwQ@mail.gmail.com>
 <CA+dygY=342rwEpGn4btVZdqdBamGEBdBfQw0DaZsuTf_9L1JWw@mail.gmail.com>
Message-ID: <nycvar.QRO.7.76.1909171507090.11153@zreyva.zlyna.ubzr>

Hi Craig:

It appears you pretty much made the definitive statement about
target_link_libraries (TLL) <INTERFACE|PUBLIC|PRIVATE> options at
<https://cmake.org/pipermail/cmake/2016-May/063400.html>.  However,
I have some further questions about this key section of your
statement:

"[...] when A links in B as PRIVATE, the include directories of B
never propagate to something linking to A, but if A is a static
library, then the *linking* of B behaves as though the relationship
was PUBLIC. This PRIVATE-becomes-PUBLIC behaviour for static libraries
only applies to the *linking*, not to the other dependencies (compiler
options/flags and include search paths). The upshot of all this is
that if you select PRIVATE, PUBLIC or INTERFACE based on the
explanations in the dot points above, then CMake will ensure
dependencies propagate through to where they are required, regardless
of whether libraries are static or shared. This does, of course, rely
on you the developer not missing any dependencies or specifying the
wrong PRIVATE/PUBLIC/INTERFACE relationship."

The issues I am concerned with are the following:

* The target_include_directories, target_compile_definitions, and
   target_compile_options (TID, TCD, and TCO) commands all have
   <INTERFACE|PUBLIC|PRIVATE> options.  I am pretty sure those options
   must take precedence over the TLL <INTERFACE|PUBLIC|PRIVATE> options,
   but can you confirm that?

* It appears to me that if a CMake-based build system is configured
   properly there is very little need for the PUBLIC option for TLL
   because PRIVATE works well for shared libraries and the
   PRIVATE-becomes-PUBLIC behaviour for static libraries you mentioned
   above.  Can you confirm this statement is generally true both for
   Unix and Windows?

I am concerned with the above issues because the PLplot build system
currently does the following:

* For shared libraries uses the PRIVATE TLL option for the Unix case
   and PUBLIC TLL option for the Windows case.

* For static libraries always uses the PUBLIC TLL option.

These decisions were based on my own understanding of transitive
linking needs for static Unix libraries and shared and static Windows
libraries many years ago, but now it appears that understanding is out
of date or else was wrong in the first place.

For example, in the static Linux case there is a nasty leakage of
compile and link flags between static libraries that I have just
tripped over when dealing with the D ldc2 compiler which cannot
understand those flags which are generated for the gcc compiler for a
C library which our D library depends on.  So to stop that leakage,
and in light of what you said three years ago, it appears to be a
no-brainer to use PRIVATE TLL for the PLplot static libraries at least
in the Unix case.  So assuming that for the PLplot build system I
follow up and prove that PRIVATE TLL works for both the shared and
static library cases on Unix, would you also recommend PLplot move to
PRIVATE TLL for both the shared and static library cases on Windows?

Thanks in advance for your further comments on these matters.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From doenges at mvtec.com  Wed Sep 18 01:50:32 2019
From: doenges at mvtec.com (Eric Doenges)
Date: Wed, 18 Sep 2019 07:50:32 +0200
Subject: [CMake] toolchain file - cross-compiling
 windows-amd64->windows-x86
In-Reply-To: <a30f8feb-798d-492a-933d-2ff89e8ed630@www.fastmail.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
 <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
 <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
 <CAEHOsR3gjhs5gwKrBsVxYu1F-m+brzZU7JBvQDiGsVmk2Nq2qw@mail.gmail.com>
 <CAB57kXpqq3EJrAmm0DnkOx5VMwWUVt9s3Gicc-8SL-upzpiPWA@mail.gmail.com>
 <CAEHOsR1p_ysZB1jO=e3zzeTfM4Xx9_=GO5e9_ZcfPmWXQEKwDg@mail.gmail.com>
 <CAB57kXpvQj6x4drQxxq90h0dWTzvsHgN0YvPoVTFyJuqF-gL5Q@mail.gmail.com>
 <a30f8feb-798d-492a-933d-2ff89e8ed630@www.fastmail.com>
Message-ID: <2bcb2bd7-0a29-6a0d-9a9d-1686a9f9e72f@mvtec.com>

We use ninja for building on Windows. Our toolchain file for the MSVC 
compiler is really simple (this is for MSVC 18.0, 32 bits):

--- SNIP ---

set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR "x86")
set(CMAKE_SYSTEM_VERSION 1)

# Microsoft MSVC compiler
set(CMAKE_C_COMPILER cl.exe)
set(CMAKE_CXX_COMPILER cl.exe)

# Unfortunatly CMake doesn't seem to know anything about the MSVC compiler,
# so tell CMake that cl.exe supports C99
set(CMAKE_C_COMPILE_FEATURES c_std_99)

# If Visual Studio is selected as generator, only allow VS 2013
if(CMAKE_GENERATOR MATCHES "Visual Studio")
 ? if(NOT CMAKE_GENERATOR MATCHES "Visual Studio 12 2013")
 ??? message(FATAL_ERROR "Visual Studio generator requires Visual Studio 
12 2013"
 ????? " for this configuration")
 ? else()
 ??? # Enable parallel builds for Visual Studio Projects with the /MP flag
 ??? set(_MP_FLAG "/MP")
 ? endif()
endif()

set(CMAKE_C_FLAGS_INIT?? "/arch:SSE2 ${_MP_FLAG} /EHsc")
set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")

--- SNIP ---

However, there is a major snag (naturally, since we're talking about 
Windows here) - in order for the Microsoft compiler to work from the 
command line, you need to set the correct environment, and CMake doesn't 
really give you a good way to do this. You can set environment variables 
from CMake, but as the documentation says "This command affects only the 
current CMake process, not the process from which CMake was called, nor 
the system environment at large, nor the environment of subsequent build 
or test processes.".

The solution we use is instead of calling cmake directly, we call a Perl 
script that sets up the environment correctly and then calls cmake for 
configuration or building. An alternative solution would be to write a 
batch script wrapper for cl.exe, something like.

@ECHO OFF
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86
cl.exe %*

and then set this batch script as the C and C++ compiler in CMake (note 
that this is untested - I think it should work, but it may need some 
extra work).

With kind regards,
Eric

Am 17.09.19 um 21:46 schrieb fdk17:
> As I recall for myself, simply using the Visual Studio Generator with 
> the -A option was all that was needed to build for Win32.
> You don't need a toolchain file because the generator already knows 
> how to setup a Visual Studio Project to target Win32.
> Even the documentation for cross-compiling doesn't show a need to 
> setup toolchain file for cross compiling in this case.
>
> I personally never seen anyone try to use the Ninja generator via 
> command line CMake and use the cl.exe compiler.
> I've only seen that using Visual Studio to open a CMakeLists.txt file 
> it can produce a Ninja project.? But even MS documentation states that 
> it doesn't always work.
>
> https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
> This says you should be able to open the proper development window and 
> use Ninja.
>
> The output shows that in the environment you are using it doesn't even 
> know how to use cl.exe to even determine with compiler it is.? Maybe 
> not all the proper environment variables and paths are being set 
> correctly when using the compiler.
>
> --
> F
-- 

*Dr. Eric D?nges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doenges at mvtec.com <mailto:mustermann at mvtec.com> | Tel: +49 89 457 695-0 
| www.mvtec.com <http://www.mvtec.com>

Find our privacy policy here <https://www.mvtec.com/imprint>.

Sign up <https://www.mvtec.com/newsletter> for our MVTec Newsletter!

Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht M?nchen HRB 114695

MVTec Software GmbH Logo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190918/7cc63d51/attachment.html>

From Simon.Richter at hogyros.de  Wed Sep 18 05:56:16 2019
From: Simon.Richter at hogyros.de (Simon Richter)
Date: Wed, 18 Sep 2019 11:56:16 +0200
Subject: [CMake] Difference between PRIVATE and PUBLIC with
 target_link_libraries
In-Reply-To: <nycvar.QRO.7.76.1909171507090.11153@zreyva.zlyna.ubzr>
References: <20160510075948.1f445585@posteo.de>
 <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com>
 <20160511071355.7209ed8a@vdr>
 <CAGyo1ox+D+Maa2QL8iDEx12cxNfU6DfpKLgaz5W-=Dk5R+WvwQ@mail.gmail.com>
 <CA+dygY=342rwEpGn4btVZdqdBamGEBdBfQw0DaZsuTf_9L1JWw@mail.gmail.com>
 <nycvar.QRO.7.76.1909171507090.11153@zreyva.zlyna.ubzr>
Message-ID: <20190918095616.GD5872@psi5.com>

Hi,

On Tue, Sep 17, 2019 at 04:21:36PM -0700, Alan W. Irwin wrote:

> * It appears to me that if a CMake-based build system is configured
>   properly there is very little need for the PUBLIC option for TLL
>   because PRIVATE works well for shared libraries and the
>   PRIVATE-becomes-PUBLIC behaviour for static libraries you mentioned
>   above.  Can you confirm this statement is generally true both for
>   Unix and Windows?

The PUBLIC option is required if your library has inline functions that
directly call a dependent library.

On Windows, "shared" linking uses import stubs. Symbols used by dependent
libs were resolved when the dependent lib was linked, so they are not
available anymore. On ELF systems, whether symbols from indirectly linked
libs are available is implementation dependent -- older versions of glibc's
ld.so built a global namespace, so it might appear to work there, but that
is not guaranteed.

My expectation is that PRIVATE should work in all cases as long as your use
of the dependent library is indeed private -- i.e. doesn't affect the
binary interface of your library. Ideally, your headers wouldn't include
their headers, but in reality requirements are a bit more relaxed, so you
are fine as long as you don't have inline functions in headers that call
into the private dependency, and any compiler flags that affect data layout
in any shared types are consistent (e.g. if you use GLM, then
the definition of GLM_FORCE_PURE must be PUBLIC, because that affects
struct alignment requirements).

A good way to test is to do a fully static build with a compiler that
supports link time optimization and provides diagnostics for mismatches.
For example, we know we have a bug in the way KiCad uses GLM, because we
get -Wlto warnings[1] about that.

   Simon

[1] https://jenkins.simonrichter.eu/job/linux-kicad-head-lto/24/gcc/

From jp_abreu at id.uff.br  Wed Sep 18 12:39:06 2019
From: jp_abreu at id.uff.br (Joao Pedro Abreu De Souza)
Date: Wed, 18 Sep 2019 13:39:06 -0300
Subject: [CMake] toolchain file - cross-compiling
 windows-amd64->windows-x86
In-Reply-To: <2bcb2bd7-0a29-6a0d-9a9d-1686a9f9e72f@mvtec.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
 <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
 <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
 <CAEHOsR3gjhs5gwKrBsVxYu1F-m+brzZU7JBvQDiGsVmk2Nq2qw@mail.gmail.com>
 <CAB57kXpqq3EJrAmm0DnkOx5VMwWUVt9s3Gicc-8SL-upzpiPWA@mail.gmail.com>
 <CAEHOsR1p_ysZB1jO=e3zzeTfM4Xx9_=GO5e9_ZcfPmWXQEKwDg@mail.gmail.com>
 <CAB57kXpvQj6x4drQxxq90h0dWTzvsHgN0YvPoVTFyJuqF-gL5Q@mail.gmail.com>
 <a30f8feb-798d-492a-933d-2ff89e8ed630@www.fastmail.com>
 <2bcb2bd7-0a29-6a0d-9a9d-1686a9f9e72f@mvtec.com>
Message-ID: <CAB57kXp8dwe=adCz8Rq3g6PUaYRQo87-sXU-7JHAa9ViTgYHXg@mail.gmail.com>

Cool. I try using this toolchain in a toy project, just to test, and
execute the cmake inside cross-compiling x64_x86 from visual studio 2017
and all work as expected, except the linking from ninja, that break because
cannot find printf.
Is absolutely cool, better than my last toolchain. Do you know how Can I
link with libc from visual studio 2013(that was your example)? From
location on 2013, the 2017 can be deduced, I think.

To make clear, when I said how to link with libc, is literally the path
that I don't know kkkk, I know that must use libpath(or set LIB env
variable) with the path, but what path? kkk

Em qua, 18 de set de 2019 ?s 02:50, Eric Doenges <doenges at mvtec.com>
escreveu:

> We use ninja for building on Windows. Our toolchain file for the MSVC
> compiler is really simple (this is for MSVC 18.0, 32 bits):
>
> --- SNIP ---
>
> set(CMAKE_SYSTEM_NAME Windows)
> set(CMAKE_SYSTEM_PROCESSOR "x86")
> set(CMAKE_SYSTEM_VERSION 1)
>
> # Microsoft MSVC compiler
> set(CMAKE_C_COMPILER cl.exe)
> set(CMAKE_CXX_COMPILER cl.exe)
>
> # Unfortunatly CMake doesn't seem to know anything about the MSVC compiler,
> # so tell CMake that cl.exe supports C99
> set(CMAKE_C_COMPILE_FEATURES c_std_99)
>
> # If Visual Studio is selected as generator, only allow VS 2013
> if(CMAKE_GENERATOR MATCHES "Visual Studio")
>   if(NOT CMAKE_GENERATOR MATCHES "Visual Studio 12 2013")
>     message(FATAL_ERROR "Visual Studio generator requires Visual Studio 12
> 2013"
>       " for this configuration")
>   else()
>     # Enable parallel builds for Visual Studio Projects with the /MP flag
>     set(_MP_FLAG "/MP")
>   endif()
> endif()
>
> set(CMAKE_C_FLAGS_INIT   "/arch:SSE2 ${_MP_FLAG} /EHsc")
> set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")
>
> --- SNIP ---
>
> However, there is a major snag (naturally, since we're talking about
> Windows here) - in order for the Microsoft compiler to work from the
> command line, you need to set the correct environment, and CMake doesn't
> really give you a good way to do this. You can set environment variables
> from CMake, but as the documentation says "This command affects only the
> current CMake process, not the process from which CMake was called, nor the
> system environment at large, nor the environment of subsequent build or
> test processes.".
>
> The solution we use is instead of calling cmake directly, we call a Perl
> script that sets up the environment correctly and then calls cmake for
> configuration or building. An alternative solution would be to write a
> batch script wrapper for cl.exe, something like.
>
> @ECHO OFF
> "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86
> cl.exe %*
>
> and then set this batch script as the C and C++ compiler in CMake (note
> that this is untested - I think it should work, but it may need some extra
> work).
>
> With kind regards,
> Eric
> Am 17.09.19 um 21:46 schrieb fdk17:
>
> As I recall for myself, simply using the Visual Studio Generator with the
> -A option was all that was needed to build for Win32.
> You don't need a toolchain file because the generator already knows how to
> setup a Visual Studio Project to target Win32.
> Even the documentation for cross-compiling doesn't show a need to setup
> toolchain file for cross compiling in this case.
>
> I personally never seen anyone try to use the Ninja generator via command
> line CMake and use the cl.exe compiler.
> I've only seen that using Visual Studio to open a CMakeLists.txt file it
> can produce a Ninja project.  But even MS documentation states that it
> doesn't always work.
>
>
> https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
> This says you should be able to open the proper development window and use
> Ninja.
>
> The output shows that in the environment you are using it doesn't even
> know how to use cl.exe to even determine with compiler it is.  Maybe not
> all the proper environment variables and paths are being set correctly when
> using the compiler.
>
> --
> F
>
> --
>
> *Dr. Eric D?nges*
> Senior Software Engineer
>
> MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
> doenges at mvtec.com <mustermann at mvtec.com> | Tel: +49 89 457 695-0 |
> www.mvtec.com
>
> Find our privacy policy here <https://www.mvtec.com/imprint>.
>
>  Sign up <https://www.mvtec.com/newsletter> for our MVTec Newsletter!
>
> Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
> Amtsgericht M?nchen HRB 114695
>
>
> [image: MVTec Software GmbH Logo]
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190918/d8003edb/attachment.html>

From marek.vojtko at oxidegames.com  Wed Sep 18 14:55:55 2019
From: marek.vojtko at oxidegames.com (Marek Vojtko)
Date: Wed, 18 Sep 2019 18:55:55 +0000
Subject: [CMake] [VS] Error Code Return from add_custom_command() Suppresses
 Console Output
Message-ID: <MWHPR19MB01109C71EFFC2D9F88B76D1EEA8E0@MWHPR19MB0110.namprd19.prod.outlook.com>

Hi,

I have a custom command that calls an in-house compiler that generates a source file set up like this:

add_custom_command(OUTPUT "generatedFile.h" COMMAND "myCompiler.exe -someParam" [..])

The compiler prints information to STDOUT like lines where errors or warnings occurred.

When the command succeeds (i.e. the compilation succeeds and myCompiler.exe returns 0), the compiler's output is correctly printed into the compile output (the Build Output window in Visual Studio):

> Generating generatedFile.h
>
> <path/to/myCompiler.exe> -someParam
>
> [output from the compiler, including file names and line numbers for warnings]

However, when the command fails (i.e. the compilation fails and myCompiler.exe returns a non-zero return code), I don't see the compiler's output. Instead I get:

> C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(209,5): error MSB6006: "cmd.exe" exited with code -2147483645.

I get this behavior on CMake 3.12 and 3.15. I have tried adding VERBATIM and USES_TERMINAL to my add_custom_command() call, but neither helped.

How can I get the custom command's output even when it returns a non-zero return code?

Thanks,
Marek

From doenges at mvtec.com  Thu Sep 19 01:58:03 2019
From: doenges at mvtec.com (Eric Doenges)
Date: Thu, 19 Sep 2019 07:58:03 +0200
Subject: [CMake] toolchain file - cross-compiling
 windows-amd64->windows-x86
In-Reply-To: <CAB57kXp8dwe=adCz8Rq3g6PUaYRQo87-sXU-7JHAa9ViTgYHXg@mail.gmail.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
 <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
 <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
 <CAEHOsR3gjhs5gwKrBsVxYu1F-m+brzZU7JBvQDiGsVmk2Nq2qw@mail.gmail.com>
 <CAB57kXpqq3EJrAmm0DnkOx5VMwWUVt9s3Gicc-8SL-upzpiPWA@mail.gmail.com>
 <CAEHOsR1p_ysZB1jO=e3zzeTfM4Xx9_=GO5e9_ZcfPmWXQEKwDg@mail.gmail.com>
 <CAB57kXpvQj6x4drQxxq90h0dWTzvsHgN0YvPoVTFyJuqF-gL5Q@mail.gmail.com>
 <a30f8feb-798d-492a-933d-2ff89e8ed630@www.fastmail.com>
 <2bcb2bd7-0a29-6a0d-9a9d-1686a9f9e72f@mvtec.com>
 <CAB57kXp8dwe=adCz8Rq3g6PUaYRQo87-sXU-7JHAa9ViTgYHXg@mail.gmail.com>
Message-ID: <99e7cc49-8f5b-b3ef-40a8-16c556acff4e@mvtec.com>

If the environment is set up correctly, the MSVC tools should be able to 
find the correct versions of the runtime libraries automatically. If you 
are using the wrapper script approach, the problem is most likely that 
when using MSVC, linking is done by calling the linker directly instead 
of indirectly via the compiler driver (as is common on Unix-like 
systems). So you also need a wrapper for link.exe that sets up the 
environment, and tell CMake to use that by setting CMAKE_LINKER to the 
name of the wrapper script.

With kind regards,
Eric

Am 18.09.19 um 18:39 schrieb Joao Pedro Abreu De Souza:
> Cool. I try using this toolchain in a toy project, just to test, and 
> execute the cmake inside cross-compiling x64_x86 from visual studio 
> 2017 and all work as expected, except the linking from ninja, that 
> break because cannot find printf.
> Is absolutely cool, better than my last toolchain. Do you know how Can 
> I link with libc from visual studio 2013(that was your example)? From 
> location on 2013, the 2017 can be deduced, I think.
>
> To make clear, when I said how to link with libc, is literally the 
> path that I don't know kkkk, I know that must use libpath(or set LIB 
> env variable) with the path, but what path? kkk
>
> Em qua, 18 de set de 2019 ?s 02:50, Eric Doenges <doenges at mvtec.com 
> <mailto:doenges at mvtec.com>> escreveu:
>
>     We use ninja for building on Windows. Our toolchain file for the
>     MSVC compiler is really simple (this is for MSVC 18.0, 32 bits):
>
>     --- SNIP ---
>
>     set(CMAKE_SYSTEM_NAME Windows)
>     set(CMAKE_SYSTEM_PROCESSOR "x86")
>     set(CMAKE_SYSTEM_VERSION 1)
>
>     # Microsoft MSVC compiler
>     set(CMAKE_C_COMPILER cl.exe)
>     set(CMAKE_CXX_COMPILER cl.exe)
>
>     # Unfortunatly CMake doesn't seem to know anything about the MSVC
>     compiler,
>     # so tell CMake that cl.exe supports C99
>     set(CMAKE_C_COMPILE_FEATURES c_std_99)
>
>     # If Visual Studio is selected as generator, only allow VS 2013
>     if(CMAKE_GENERATOR MATCHES "Visual Studio")
>     ? if(NOT CMAKE_GENERATOR MATCHES "Visual Studio 12 2013")
>     ??? message(FATAL_ERROR "Visual Studio generator requires Visual
>     Studio 12 2013"
>     ????? " for this configuration")
>     ? else()
>     ??? # Enable parallel builds for Visual Studio Projects with the
>     /MP flag
>     ??? set(_MP_FLAG "/MP")
>     ? endif()
>     endif()
>
>     set(CMAKE_C_FLAGS_INIT?? "/arch:SSE2 ${_MP_FLAG} /EHsc")
>     set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")
>
>     --- SNIP ---
>
>     However, there is a major snag (naturally, since we're talking
>     about Windows here) - in order for the Microsoft compiler to work
>     from the command line, you need to set the correct environment,
>     and CMake doesn't really give you a good way to do this. You can
>     set environment variables from CMake, but as the documentation
>     says "This command affects only the current CMake process, not the
>     process from which CMake was called, nor the system environment at
>     large, nor the environment of subsequent build or test processes.".
>
>     The solution we use is instead of calling cmake directly, we call
>     a Perl script that sets up the environment correctly and then
>     calls cmake for configuration or building. An alternative solution
>     would be to write a batch script wrapper for cl.exe, something like.
>
>     @ECHO OFF
>     "C:\Program Files (x86)\Microsoft Visual Studio
>     12.0\VC\vcvarsall.bat" x86
>     cl.exe %*
>
>     and then set this batch script as the C and C++ compiler in CMake
>     (note that this is untested - I think it should work, but it may
>     need some extra work).
>
>     With kind regards,
>     Eric
>
>     Am 17.09.19 um 21:46 schrieb fdk17:
>>     As I recall for myself, simply using the Visual Studio Generator
>>     with the -A option was all that was needed to build for Win32.
>>     You don't need a toolchain file because the generator already
>>     knows how to setup a Visual Studio Project to target Win32.
>>     Even the documentation for cross-compiling doesn't show a need to
>>     setup toolchain file for cross compiling in this case.
>>
>>     I personally never seen anyone try to use the Ninja generator via
>>     command line CMake and use the cl.exe compiler.
>>     I've only seen that using Visual Studio to open a CMakeLists.txt
>>     file it can produce a Ninja project.? But even MS documentation
>>     states that it doesn't always work.
>>
>>     https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
>>     This says you should be able to open the proper development
>>     window and use Ninja.
>>
>>     The output shows that in the environment you are using it doesn't
>>     even know how to use cl.exe to even determine with compiler it
>>     is.? Maybe not all the proper environment variables and paths are
>>     being set correctly when using the compiler.
>>
>>     --
>>     F
>     -- 
>
>     *Dr. Eric D?nges*
>     Senior Software Engineer
>
>     MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
>     doenges at mvtec.com <mailto:mustermann at mvtec.com> | Tel: +49 89 457
>     695-0 | www.mvtec.com <http://www.mvtec.com>
>
>     Find our privacy policy here <https://www.mvtec.com/imprint>.
>
>     Sign up <https://www.mvtec.com/newsletter> for our MVTec Newsletter!
>
>     Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
>     Amtsgericht M?nchen HRB 114695
>
>     MVTec Software GmbH Logo
>     -- 
>
>     Powered by www.kitware.com <http://www.kitware.com>
>
>     Please keep messages on-topic and check the CMake FAQ at:
>     http://www.cmake.org/Wiki/CMake_FAQ
>
>     Kitware offers various services to support the CMake community.
>     For more information on each offering, please visit:
>
>     CMake Support: http://cmake.org/cmake/help/support.html
>     CMake Consulting: http://cmake.org/cmake/help/consulting.html
>     CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>     Visit other Kitware open-source projects at
>     http://www.kitware.com/opensource/opensource.html
>
>     Follow this link to subscribe/unsubscribe:
>     https://cmake.org/mailman/listinfo/cmake
>
-- 

*Dr. Eric D?nges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doenges at mvtec.com <mailto:mustermann at mvtec.com> | Tel: +49 89 457 695-0 
| www.mvtec.com <http://www.mvtec.com>

Find our privacy policy here <https://www.mvtec.com/imprint>.

Sign up <https://www.mvtec.com/newsletter> for our MVTec Newsletter!

Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht M?nchen HRB 114695

MVTec Software GmbH Logo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190919/36ee13c6/attachment-0001.html>

From ggarra13 at gmail.com  Thu Sep 19 13:02:34 2019
From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=)
Date: Thu, 19 Sep 2019 14:02:34 -0300
Subject: [CMake] toolchain file - cross-compiling
 windows-amd64->windows-x86
In-Reply-To: <a30f8feb-798d-492a-933d-2ff89e8ed630@www.fastmail.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
 <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
 <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
 <CAEHOsR3gjhs5gwKrBsVxYu1F-m+brzZU7JBvQDiGsVmk2Nq2qw@mail.gmail.com>
 <CAB57kXpqq3EJrAmm0DnkOx5VMwWUVt9s3Gicc-8SL-upzpiPWA@mail.gmail.com>
 <CAEHOsR1p_ysZB1jO=e3zzeTfM4Xx9_=GO5e9_ZcfPmWXQEKwDg@mail.gmail.com>
 <CAB57kXpvQj6x4drQxxq90h0dWTzvsHgN0YvPoVTFyJuqF-gL5Q@mail.gmail.com>
 <a30f8feb-798d-492a-933d-2ff89e8ed630@www.fastmail.com>
Message-ID: <8d5e06b3-5b11-3d54-d5f0-8b7815e0bf38@gmail.com>


El 17/9/19 a las 16:46, fdk17 escribi?:
>
> I personally never seen anyone try to use the Ninja generator via 
> command line CMake and use the cl.exe compiler.
> I've only seen that using Visual Studio to open a CMakeLists.txt file 
> it can produce a Ninja project.? But even MS documentation states that 
> it doesn't always work.

I use it just like that.? I open a .bat file that calls vsvars with the 
right settings and then calls msys bash. Find it below:


@echo off

call "C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/vcvarsall.bat" amd64 8.1
C:
C:\MinGW\msys\1.0\msys.bat -rxvt

Then I call cmake and ninja with a bash script (both are in the bash 
PATH).? Find it attached.


--

Gonzalo Garramu?o

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190919/c6882c4d/attachment.html>
-------------- next part --------------
#!/bin/bash

#
# Determine CPU architecture
#
KERNEL=`uname -s`

if [[ $KERNEL == CYGWIN* ]]; then
    KERNEL=Windows
    RELEASE=(`cmd /c 'ver'`)
    RELEASE=${RELEASE[3]%.[0-9]*}
elif [[ $KERNEL == MINGW* ]]; then
    RELEASE=(`cmd /c 'ver'`)
    #RELEASE=${RELEASE[3]%.[0-9]*}
    RELEASE=${RELEASE[3]/]/}
    KERNEL=Windows
else
    RELEASE=`uname -r`
fi


if [[ "$RELEASE" == "" ]]; then
    $RELEASE=`cmd.exe /c 'ver'`
    echo $RELEASE
    echo "Could not determine OS version"
    exit 1
fi

CMAKE_OPTS=${CMAKE_OPTS=""}

export CMAKE_NATIVE_ARCH=32
export CMAKE_BUILD_TYPE=Release
export CMAKE_PROCS=8
export OS_32_BITS=1
export OS_64_BITS=

if [ $KERNEL == 'Windows' ]; then
    arch=`wmic OS get OSArchitecture`
    if [[ $arch == *64* ]]; then
	CMAKE_NATIVE_ARCH=64
	export OS_64_BITS=1
    fi
else
    arch=`uname -a`
fi

if [[ $arch == *x86_64* ]]; then
    CMAKE_NATIVE_ARCH=64
    export OS_64_BITS=1
else
    if [[ $arch == *ia64* ]]; then
	CMAKE_NATIVE_ARCH=64
	export OS_64_BITS=1
	unset  OS_32_BITS
    fi
fi


export CMAKE_BUILD_ARCH=$CMAKE_NATIVE_ARCH

OS=$KERNEL-$RELEASE


usage()
{
    cat <<EOF
$0

$0 [options] [--] [make options]

Wrapper around CMake to easily create out of source builds
(ie. compilations where everything goes into a directory).

For this platform (default settings):
  BUILD/$OS-$CMAKE_BUILD_ARCH/$CMAKE_BUILD_TYPE

It must be run from a directory with a valid CMakeLists.txt
file outside of the build tree.

Options:

  -q         quiet build (default)
  -v         verbose build
  -j N       number of cpus to use (default: ${CMAKE_PROCS=8})
  -G <name>  use a different cmake generator (default: Ninja)

  debug|release|reldebug|small
  debug    - build a debug build
  release  - build a release build (default)
  reldebug - build a release build with debug information
  small    - build a small release build

  both|32|64
	     Builds both 32/64 bit versions, 32-bit only,
	     64-bit only (default: $CMAKE_BUILD_ARCH)

  cache    - Cleans all CMakeCache.txt files

  swig     - Cleans all swig files

  clean    - Cleans BUILD/$OS-$CMAKE_BUILD_ARCH/$CMAKE_BUILD_TYPE

  cmake    - Runs cmake only.

EOF
    exit 1
}

clean_cache()
{
    if [ $CMAKE_BUILD_ARCH == 'Both' ]; then
	CMAKE_BUILD_ARCH=32
	clean_cache
	CMAKE_BUILD_ARCH=64
	clean_cache
	CMAKE_BUILD_ARCH=Both
	return
    fi

    builddir=BUILD/$OS-$CMAKE_BUILD_ARCH/$CMAKE_BUILD_TYPE
    if [ ! -d $builddir ]; then
	return
    fi
    echo
    echo "Removing old cmake caches $builddir..."
    echo
    # Remove cache files
    find $builddir -name CMakeCache.txt -exec rm {} \;
    # Remove makefiles
    find $builddir -name Makefile -exec rm {} \;
}


clean_swig()
{
    if [ $CMAKE_BUILD_ARCH == 'Both' ]; then
	CMAKE_BUILD_ARCH=32
	clean_swig
	CMAKE_BUILD_ARCH=64
	clean_swig
	CMAKE_BUILD_ARCH=Both
	return
    fi

    # Remove swig wrappers
    builddir=BUILD/$OS-$CMAKE_BUILD_ARCH/$CMAKE_BUILD_TYPE
    echo
    echo "Removing old swig wrappers $builddir..."
    echo
    find $builddir -name '*_wrap.*' -exec rm {} \;
}

#
# Parse command-line options
#
clean=0
cache=0


if [[ $OS == Windows* ]]; then
    cmake_generator=Ninja
    #cmake_generator="NMake Makefiles"
    win32cl=`which cl`
    if [[ $win32cl != *amd64* ]]; then
	CMAKE_BUILD_ARCH=32
    fi
else
    cmake_generator=Ninja
fi


opts=''
RUN_MAKE=1
for i in $@; do
    case $i in
	64)
	    shift
	    CMAKE_BUILD_ARCH=64
	    ;;
	32)
	    shift
	    CMAKE_BUILD_ARCH=32
	    ;;
	both)
	    shift
	    CMAKE_BUILD_ARCH='Both'
	    ;;
	cache)
	    shift
	    cache=1
	    ;;
	clean)
	    if [ -r CMakeLists.txt ]; then
		shift
		if [ -d BUILD ]; then
		    clean=1
		fi
	    else
		break
	    fi
	    ;;
	-DCMAKE_INSTALL_PREFIX=*|--installdir=*)
	    shift
	    installdir="${i#*=}"
	    ;;
	cmake)
	    shift
	    RUN_MAKE=0
	    ;;
	debug)
	    shift
	    export CMAKE_BUILD_TYPE=Debug
	    ;;
	release)
	    shift
	    export CMAKE_BUILD_TYPE=Release
	    ;;
	small)
	    shift
	    export CMAKE_BUILD_TYPE=MinSizeRel
	    ;;
	swig)
	    shift
	    clean_swig
	    ;;
	-h)
	    shift
	    usage
	    ;;
	--help)
	    shift
	    usage
	    ;;
	-j)
	    shift
	    if [ $# == 0 ]; then
		echo "Missing parameter for -j!"
		usage
	    fi
	    CMAKE_PROCS=$1
	    shift
	    ;;
	-q)
	    shift
	    opts=""
	    ;;
	-v)
	    shift
	    opts="-v"
	    ;;
	-G)
	    shift
	    cmake_generator=$1
	    shift
	    ;;
	--)
	    shift
	    break
	    ;;
	*)
	    echo "NOT INTERPRETED: $1"
	    break
	    ;;
    esac
done


#
# Simple function to run a command and print it out
#
run_cmd()
{
    echo
    echo "> $*"
    echo
    eval command $*
}

#
# Function to just run make on a dir with a Makefile
#
run_make()
{
    if [ $RUN_MAKE == 0 ]; then
	return
    fi

    cmd=''
    if [[ $cmake_generator == NMake* ]]; then
	cmd="nmake $@"
    elif [[ $cmake_generator == Unix* ]]; then
	cmd="make -j ${CMAKE_PROCS} $@"
    elif [[ $cmake_generator == Visual* ]]; then
	return
    else
	cmd="ninja -j ${CMAKE_PROCS} $@"
    fi
    run_cmd $cmd
    status=$?
    if [ $status != 0 ]; then
	cd ../../../..
	exit $status
    fi
    cd ../../../..
}


#
# Function to run cmake and then run make on generated Makefile
#
run_cmake()
{

    builddir=$PWD/BUILD/$OS-$CMAKE_BUILD_ARCH/$CMAKE_BUILD_TYPE
    if [[ $installdir == "" ]]; then
	installdir=/usr/local
    fi

    if [[ $OS == Windows* ]]; then
	installdir="D:/code/lib/vc14_Windows_${CMAKE_BUILD_ARCH}"
	if [[ $CMAKE_BUILD_TYPE == Debug ]]; then
	   installdir="${installdir}_debug"
	fi
    fi

    if [ ! -d $installdir ]; then
	cmd="mkdir -p $installdir"
	run_cmd $cmd
    fi

    echo "Buildir ${builddir}"
    if [ ! -d $builddir ]; then
	cmd="mkdir -p $builddir $builddir/bin $builddir/lib $builddir/tmp"
	run_cmd $cmd
    fi

    cmd="cd $builddir/tmp"
    run_cmd $cmd

    if [ -r Makefile ]; then
	run_make $opts $@
	return
    fi


    pwd=$PWD

    if [[ $cmake_generator == *Makefile* ]]; then
	cmake_opts="-DCMAKE_BUILD_TYPE=$CMAKE_BUILD_TYPE"
    else
	cmake_opts="-DCMAKE_BUILD_TYPE=$CMAKE_BUILD_TYPE -DCMAKE_CFG_INTDIR=/$CMAKE_BUILD_TYPE"
    fi

    cmd="cmake ../../../.. -DCMAKE_INSTALL_PREFIX=$installdir -DEXECUTABLE_OUTPUT_PATH=$builddir/bin -DLIBRARY_OUTPUT_PATH=$builddir/lib -DCMAKE_LIBRARY_PATH=$builddir/lib -DCMAKE_NATIVE_ARCH=$CMAKE_NATIVE_ARCH -DCMAKE_BUILD_ARCH=$CMAKE_BUILD_ARCH ${cmake_opts} -G '${cmake_generator}'"


    run_cmd  $cmd
    status=$?
    if [ $status != 0 ]; then
	cd ../../../..
	exit $status
    fi

    run_make $opts $@
}

#
# Function used to clean the build directory and exit
#
run_clean()
{
    if [ $CMAKE_BUILD_ARCH == "Both" ]; then
	if [ "$OS_64_BITS" == "1" ]; then
	    CMAKE_BUILD_ARCH=64
	    run_clean
	fi
	if [ "$OS_32_BITS" == "1" ]; then
	    CMAKE_BUILD_ARCH=32
	    run_clean
	fi
	CMAKE_BUILD_ARCH=Both
	return
    fi

    builddir=BUILD/$OS-$CMAKE_BUILD_ARCH/$CMAKE_BUILD_TYPE/tmp
    if [ -d $builddir ]; then
	if [ -e ninja.build ]; then
	    run_make clean
	fi
	rm -rf $builddir/*
	echo "-------------------------------"
	echo "Cleaned $builddir"
	echo "-------------------------------"
	clean_cache
    fi
}


#
# Main routine
#
if [ $clean == 1 ]; then
    run_clean
    exit 0
elif [ $cache == 1 ]; then
    clean_cache
fi

if [ -r Makefile ]; then
    run_make $opts $@
else

    if [ ! -r CMakeLists.txt ]; then
	echo "No Makefile or CMakeLists.txt in current directory!"
	exit 1
    fi

    if [ ! -d BUILD ]; then
	mkdir BUILD
    fi

    if [ $CMAKE_BUILD_ARCH == 'Both' ]; then
	if [ "$OS_32_BITS" == "1" ]; then
	    export CMAKE_BUILD_ARCH=32
	    if [ "$OS_64_BITS" == "1" ]; then
		export LDFLAGS=-m32 ${LDFLAGS}
		export CXXFLAGS=-m32 ${CXXFLAGS}
		export CFLAGS=-m32 ${CFLAGS}
	    fi
	    run_cmake $opts $@
	fi

	if [ "$OS_64_BITS" == "1" ]; then
	    export CMAKE_BUILD_ARCH=64
	    export LDFLAGS=${LDFLAGS}
	    export CXXFLAGS=${CXXFLAGS}
	    export CFLAGS=${CFLAGS}
	    run_cmake $opts $@
	fi
    else
	run_cmake $opts $@
    fi
fi

From jp_abreu at id.uff.br  Thu Sep 19 13:59:46 2019
From: jp_abreu at id.uff.br (Joao Pedro Abreu De Souza)
Date: Thu, 19 Sep 2019 14:59:46 -0300
Subject: [CMake] toolchain file - cross-compiling
 windows-amd64->windows-x86
In-Reply-To: <8d5e06b3-5b11-3d54-d5f0-8b7815e0bf38@gmail.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
 <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
 <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
 <CAEHOsR3gjhs5gwKrBsVxYu1F-m+brzZU7JBvQDiGsVmk2Nq2qw@mail.gmail.com>
 <CAB57kXpqq3EJrAmm0DnkOx5VMwWUVt9s3Gicc-8SL-upzpiPWA@mail.gmail.com>
 <CAEHOsR1p_ysZB1jO=e3zzeTfM4Xx9_=GO5e9_ZcfPmWXQEKwDg@mail.gmail.com>
 <CAB57kXpvQj6x4drQxxq90h0dWTzvsHgN0YvPoVTFyJuqF-gL5Q@mail.gmail.com>
 <a30f8feb-798d-492a-933d-2ff89e8ed630@www.fastmail.com>
 <8d5e06b3-5b11-3d54-d5f0-8b7815e0bf38@gmail.com>
Message-ID: <CAB57kXoKv-mnuc2739=604x45wC689VKxEMex91MYRGOsNyqcw@mail.gmail.com>

Now, with this toolchain file:
-----start of toolchain file-------
set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR "x86")
set(CMAKE_SYSTEM_VERSION 1)

# Microsoft MSVC compiler
#set(CMAKE_C_COMPILER cl.exe)
#set(CMAKE_CXX_COMPILER cl.exe)

set(CMAKE_C_COMPILER
"${CMAKE_CURRENT_SOURCE_DIR}/ninja-core-lib/toolchains/cl.bat")
set(CMAKE_CXX_COMPILER "${CMAKE_C_COMPILER}")

# Unfortunatly CMake doesn't seem to know anything about the MSVC compiler,
# so tell CMake that cl.exe supports C99
set(CMAKE_C_COMPILE_FEATURES c_std_99)


set(CMAKE_C_FLAGS_INIT   "/arch:SSE2 ${_MP_FLAG} /EHsc")
set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")



#set(CMAKE_STATIC_LINKER link.exe)
#set(CMAKE_LINKER link.exe)
#set(CMAKE_SHARED_LINKER link.exe)

set(CMAKE_STATIC_LINKER
"${CMAKE_CURRENT_SOURCE_DIR}/ninja-core-lib/toolchains/link.bat")
set(CMAKE_LINKER ${CMAKE_STATIC_LINKER})
set(CMAKE_SHARED_LINKER ${CMAKE_STATIC_LINKER})


set(CMAKE_AR ${CMAKE_LINKER})

set(CMAKE_C_COMPILER_ID "porquePreciseiDeUmBat")
-----stop of toolchain file-------

using this cl.bat
----start of cl.bat---------
pushd
"C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"
popd
cl.exe %*
----stop of cl.bat---------

and link.bat in the same spirit but with link.exe instead of cl.exe, I can
execute cmake, ninja, but the main.exe don't are on build/src/main


When I look on CMakeError.log on build directory, can look

-------start of CMakeError.log--------------------------
C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles>more
CMakeError.log
Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Checking whether the C compiler is IAR using "" did not match "IAR .+
Compiler":

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>pushd

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>"C:/Program
Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.9.16
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64_x86'
Checking whether the C compiler is IAR using "" did not match "IAR .+
Compiler":

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>pushd

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>"C:/Program
Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.9.16
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64_x86'
Detecting C compiler ABI info failed to compile with the following output:
Change Dir:
C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp

Run Build Command(s):C:/ProgramData/chocolatey/bin/ninja.exe cmTC_8a08d &&
[1/2] Building C object CMakeFiles\cmTC_8a08d.dir\CMakeCCompilerABI.c.obj

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\CMakeTmp>pushd

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\CMakeTmp>"C:/Program
Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.9.16
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64_x86'
[2/2] Linking C executable cmTC_8a08d.exe

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\CMakeTmp>pushd

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\CMakeTmp>"C:/Program
Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.9.16
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64_x86'


Cannot copy output executable
  ''
to destination specified by COPY_FILE:

'C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CMakeDetermineCompilerABI_C.bin'
Unable to find the executable at any of:

C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp/cmTC_8a08d.exe

C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp/Debug/cmTC_8a08d.exe

C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp/Development/cmTC_8a08d.exe
-------stop of CMakeError.log--------------------------

I am not understanding the last error. All this files are my (are under
Users/jpabreu), so I don't think that may be permission problems.

Em qui, 19 de set de 2019 ?s 14:02, Gonzalo Garramu?o <ggarra13 at gmail.com>
escreveu:

>
> El 17/9/19 a las 16:46, fdk17 escribi?:
>
>
> I personally never seen anyone try to use the Ninja generator via command
> line CMake and use the cl.exe compiler.
> I've only seen that using Visual Studio to open a CMakeLists.txt file it
> can produce a Ninja project.  But even MS documentation states that it
> doesn't always work.
>
> I use it just like that.  I open a .bat file that calls vsvars with the
> right settings and then calls msys bash. Find it below:
>
>
> @echo off
>
> call "C:/Program Files (x86)/Microsoft Visual Studio
> 14.0/VC/vcvarsall.bat" amd64 8.1
> C:
> C:\MinGW\msys\1.0\msys.bat -rxvt
>
> Then I call cmake and ninja with a bash script (both are in the bash
> PATH).  Find it attached.
>
>
> --
>
> Gonzalo Garramu?o
>
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190919/e3811c03/attachment-0001.html>

From juan.e.sanchez at gmail.com  Thu Sep 19 15:47:59 2019
From: juan.e.sanchez at gmail.com (Juan E. Sanchez)
Date: Thu, 19 Sep 2019 14:47:59 -0500
Subject: [CMake] toolchain file - cross-compiling
 windows-amd64->windows-x86
In-Reply-To: <CAB57kXoKv-mnuc2739=604x45wC689VKxEMex91MYRGOsNyqcw@mail.gmail.com>
References: <CAB57kXpJSA8NDRAi74qX6Uu2Hb_xM9cd70w58hy6Ye-USQjD2A@mail.gmail.com>
 <622cdea5-6a5d-2179-a4cf-db7756542a7d@numalliance.com>
 <CAB57kXqx1Hy3Unej5qgsWhVcRuWR3UrZteQN6pbFAifCohnDtQ@mail.gmail.com>
 <CAEHOsR3gjhs5gwKrBsVxYu1F-m+brzZU7JBvQDiGsVmk2Nq2qw@mail.gmail.com>
 <CAB57kXpqq3EJrAmm0DnkOx5VMwWUVt9s3Gicc-8SL-upzpiPWA@mail.gmail.com>
 <CAEHOsR1p_ysZB1jO=e3zzeTfM4Xx9_=GO5e9_ZcfPmWXQEKwDg@mail.gmail.com>
 <CAB57kXpvQj6x4drQxxq90h0dWTzvsHgN0YvPoVTFyJuqF-gL5Q@mail.gmail.com>
 <a30f8feb-798d-492a-933d-2ff89e8ed630@www.fastmail.com>
 <8d5e06b3-5b11-3d54-d5f0-8b7815e0bf38@gmail.com>
 <CAB57kXoKv-mnuc2739=604x45wC689VKxEMex91MYRGOsNyqcw@mail.gmail.com>
Message-ID: <2e627b13-a177-1031-acb1-b1fa22e982d8@gmail.com>

Hello,

Perhaps you can start by not using the .bat scripts and using the .exe 
instead.  You can run cmake from a visual studio environment, and 
instead of invoking a visual studio environment for each command.

And to build from your script:
cmake --build .

Regards,

Juan


On 9/19/19 12:59 PM, Joao Pedro Abreu De Souza wrote:
> Now, with this toolchain file:
> -----start of toolchain file-------
> set(CMAKE_SYSTEM_NAME Windows)
> set(CMAKE_SYSTEM_PROCESSOR "x86")
> set(CMAKE_SYSTEM_VERSION 1)
> 
> # Microsoft MSVC compiler
> #set(CMAKE_C_COMPILER cl.exe)
> #set(CMAKE_CXX_COMPILER cl.exe)
> 
> set(CMAKE_C_COMPILER 
> "${CMAKE_CURRENT_SOURCE_DIR}/ninja-core-lib/toolchains/cl.bat")
> set(CMAKE_CXX_COMPILER "${CMAKE_C_COMPILER}")
> 
> # Unfortunatly CMake doesn't seem to know anything about the MSVC compiler,
> # so tell CMake that cl.exe supports C99
> set(CMAKE_C_COMPILE_FEATURES c_std_99)
> 
> 
> set(CMAKE_C_FLAGS_INIT ? "/arch:SSE2 ${_MP_FLAG} /EHsc")
> set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")
> 
> 
> 
> #set(CMAKE_STATIC_LINKER link.exe)
> #set(CMAKE_LINKER link.exe)
> #set(CMAKE_SHARED_LINKER link.exe)
> 
> set(CMAKE_STATIC_LINKER 
> "${CMAKE_CURRENT_SOURCE_DIR}/ninja-core-lib/toolchains/link.bat")
> set(CMAKE_LINKER ${CMAKE_STATIC_LINKER})
> set(CMAKE_SHARED_LINKER ${CMAKE_STATIC_LINKER})
> 
> 
> set(CMAKE_AR ${CMAKE_LINKER})
> 
> set(CMAKE_C_COMPILER_ID "porquePreciseiDeUmBat")
> -----stop of toolchain file-------
> 
> using this cl.bat
> ----start of cl.bat---------
> pushd
> "C:/Program Files (x86)/Microsoft Visual 
> Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"
> popd
> cl.exe %*
> ----stop of cl.bat---------
> 
> and link.bat in the same spirit but with link.exe instead of cl.exe, I 
> can execute cmake, ninja, but the main.exe don't are on build/src/main
> 
> 
> When I look on CMakeError.log on build directory, can look
> 
> -------start of CMakeError.log--------------------------
> C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles>more 
> CMakeError.log
> Compilation of the C compiler identification source "CMakeCCompilerId.c" 
> did not produce an executable in 
> "C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".
> 
> Compilation of the C compiler identification source "CMakeCCompilerId.c" 
> did not produce an executable in 
> "C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".
> 
> Compilation of the C compiler identification source "CMakeCCompilerId.c" 
> did not produce an executable in 
> "C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".
> 
> Compilation of the C compiler identification source "CMakeCCompilerId.c" 
> did not produce an executable in 
> "C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".
> 
> Compilation of the C compiler identification source "CMakeCCompilerId.c" 
> did not produce an executable in 
> "C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".
> 
> Compilation of the C compiler identification source "CMakeCCompilerId.c" 
> did not produce an executable in 
> "C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".
> 
> Compilation of the C compiler identification source "CMakeCCompilerId.c" 
> did not produce an executable in 
> "C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".
> 
> Compilation of the C compiler identification source "CMakeCCompilerId.c" 
> did not produce an executable in 
> "C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".
> 
> Compilation of the C compiler identification source "CMakeCCompilerId.c" 
> did not produce an executable in 
> "C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".
> 
> Compilation of the C compiler identification source "CMakeCCompilerId.c" 
> did not produce an executable in 
> "C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".
> 
> Checking whether the C compiler is IAR using "" did not match "IAR .+ 
> Compiler":
> 
> C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>pushd
> 
> C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>"C:/Program 
> Files (x86)/Microsoft Visual 
> Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"
> **********************************************************************
> ** Visual Studio 2017 Developer Command Prompt v15.9.16
> ** Copyright (c) 2017 Microsoft Corporation
> **********************************************************************
> [vcvarsall.bat] Environment initialized for: 'x64_x86'
> Checking whether the C compiler is IAR using "" did not match "IAR .+ 
> Compiler":
> 
> C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>pushd
> 
> C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>"C:/Program 
> Files (x86)/Microsoft Visual 
> Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"
> **********************************************************************
> ** Visual Studio 2017 Developer Command Prompt v15.9.16
> ** Copyright (c) 2017 Microsoft Corporation
> **********************************************************************
> [vcvarsall.bat] Environment initialized for: 'x64_x86'
> Detecting C compiler ABI info failed to compile with the following output:
> Change Dir: 
> C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp
> 
> Run Build Command(s):C:/ProgramData/chocolatey/bin/ninja.exe cmTC_8a08d 
> && [1/2] Building C object CMakeFiles\cmTC_8a08d.dir\CMakeCCompilerABI.c.obj
> 
> C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\CMakeTmp>pushd
> 
> C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\CMakeTmp>"C:/Program 
> Files (x86)/Microsoft Visual 
> Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"
> **********************************************************************
> ** Visual Studio 2017 Developer Command Prompt v15.9.16
> ** Copyright (c) 2017 Microsoft Corporation
> **********************************************************************
> [vcvarsall.bat] Environment initialized for: 'x64_x86'
> [2/2] Linking C executable cmTC_8a08d.exe
> 
> C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\CMakeTmp>pushd
> 
> C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\CMakeTmp>"C:/Program 
> Files (x86)/Microsoft Visual 
> Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"
> **********************************************************************
> ** Visual Studio 2017 Developer Command Prompt v15.9.16
> ** Copyright (c) 2017 Microsoft Corporation
> **********************************************************************
> [vcvarsall.bat] Environment initialized for: 'x64_x86'
> 
> 
> Cannot copy output executable
>  ? ''
> to destination specified by COPY_FILE:
>    
> 'C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CMakeDetermineCompilerABI_C.bin'
> Unable to find the executable at any of:
>    
> C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp/cmTC_8a08d.exe
>    
> C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp/Debug/cmTC_8a08d.exe
>    
> C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp/Development/cmTC_8a08d.exe
> -------stop of CMakeError.log--------------------------
> 
> I am not understanding the last error. All this files are my (are under 
> Users/jpabreu), so I don't think that may be permission problems.
> 
> Em qui, 19 de set de 2019 ?s 14:02, Gonzalo Garramu?o 
> <ggarra13 at gmail.com <mailto:ggarra13 at gmail.com>> escreveu:
> 
> 
>     El 17/9/19 a las 16:46, fdk17 escribi?:
>>
>>     I personally never seen anyone try to use the Ninja generator via
>>     command line CMake and use the cl.exe compiler.
>>     I've only seen that using Visual Studio to open a CMakeLists.txt
>>     file it can produce a Ninja project.? But even MS documentation
>>     states that it doesn't always work.
> 
>     I use it just like that.? I open a .bat file that calls vsvars with
>     the right settings and then calls msys bash. Find it below:
> 
> 
>     @echo off
> 
>     call "C:/Program Files (x86)/Microsoft Visual Studio
>     14.0/VC/vcvarsall.bat" amd64 8.1
>     C:
>     C:\MinGW\msys\1.0\msys.bat -rxvt
> 
>     Then I call cmake and ninja with a bash script (both are in the bash
>     PATH).? Find it attached.
> 
> 
>     --
> 
>     Gonzalo Garramu?o
> 
>     -- 
> 
>     Powered by www.kitware.com <http://www.kitware.com>
> 
>     Please keep messages on-topic and check the CMake FAQ at:
>     http://www.cmake.org/Wiki/CMake_FAQ
> 
>     Kitware offers various services to support the CMake community. For
>     more information on each offering, please visit:
> 
>     CMake Support: http://cmake.org/cmake/help/support.html
>     CMake Consulting: http://cmake.org/cmake/help/consulting.html
>     CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
>     Visit other Kitware open-source projects at
>     http://www.kitware.com/opensource/opensource.html
> 
>     Follow this link to subscribe/unsubscribe:
>     https://cmake.org/mailman/listinfo/cmake
> 
> 


From cornelis at bockemuehl.ch  Fri Sep 20 08:49:52 2019
From: cornelis at bockemuehl.ch (=?utf-8?q?Cornelis_Bockem=C3=BChl?=)
Date: Fri, 20 Sep 2019 14:49:52 +0200
Subject: [CMake] Debug logging of items
Message-ID: <6210-5d84cb00-c3-12967640@202256610>


Right now I am fighting my way through large amounts of CMake code (actually working on a ParaView custom application with many own plugins, views, domains, property widgets etc. etc.), and it is sometimes really not easy not to lose track completely! Sometimes I am happy to be back into complex C++ programming - because I see much more logic in the entire thing. And it is of course no news that CMake code is not famous for being easy to debug.

Anyway, I am dreaming of some "simple" features that would sometimes help a lot, and it is all about "dumping" some kind of data. Actually this is for me often also the favorite way to debug C++ code: just print out the values of variables, arrays, etc. - e.g. if setting a breakpoint in the debugger is difficult because you are interested only in the 928773th occurrence of a certain piece of code (without even knowing that number...).

Accordingly in CMake code I am working a lot with the message() function - but within that code the problem is often that you do not even know which variables would be available at all!

Thus functions like would be really great to have:

??? ?give me a list of all currently known targets?
??? ?give me a list of all properties of a target?
??? ?give me a list of all currently defined variables?
??? etc.

What I do not know is: Are this things that already exist - in which case I would be happy if somebody could tell me how to find them! -, or are these functions rather "feature requests"?

In fact I can hardly believe that I am the first with such kind of dreams, so my hope is still that they already exist somewhere...

--
Cornelis Bockem?hl
mail: cornelis at bockemuehl.ch
phone: +41 79 644 9943
Basel, Switzerland
https://cobo.bockemuehl.ch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190920/8a8d25c2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6210-5D84CB00-C5-12967640
Type: image/png
Size: 16631 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190920/8a8d25c2/attachment-0001.png>

From doenges at mvtec.com  Fri Sep 20 09:07:51 2019
From: doenges at mvtec.com (Eric Doenges)
Date: Fri, 20 Sep 2019 15:07:51 +0200
Subject: [CMake] Debug logging of items
In-Reply-To: <6210-5d84cb00-c3-12967640@202256610>
References: <6210-5d84cb00-c3-12967640@202256610>
Message-ID: <92312bde-b740-1b7b-47ff-fa9f91ee3bbb@mvtec.com>

I don't know about the targets, but you can get all variables currently 
defined for a directory by reading the VARIABLES property, e.g.

get_property(_variables DIRECTORY "${CMAKE_SOURCE_DIR}" PROPERTY VARIABLES)

I use this to dump the variables into a file so I can see with which 
variable settings my build directory was configured with.

With kind regards,
Eric

Am 20.09.19 um 14:49 schrieb Cornelis Bockem?hl:
>
> Right now I am fighting my way through large amounts of CMake code 
> (actually working on a ParaView custom application with many own 
> plugins, views, domains, property widgets etc. etc.), and it is 
> sometimes really not easy not to lose track completely! Sometimes I am 
> happy to be back into complex C++ programming - because I see much 
> more logic in the entire thing. And it is of course no news that CMake 
> code is not famous for being easy to debug.
>
> Anyway, I am dreaming of some "simple" features that would sometimes 
> help a lot, and it is all about "dumping" some kind of data. Actually 
> this is for me often also the favorite way to debug C++ code: just 
> print out the values of variables, arrays, etc. - e.g. if setting a 
> breakpoint in the debugger is difficult because you are interested 
> only in the 928773th occurrence of a certain piece of code (without 
> even knowing that number...).
>
> Accordingly in CMake code I am working a lot with the message() 
> function - but within that code the problem is often that you do not 
> even know which variables would be available at all!
>
> Thus functions like would be really great to have:
>
> ??? ?give me a list of all currently known targets?
> ??? ?give me a list of all properties of a target?
> ??? ?give me a list of all currently defined variables?
> ??? etc.
>
> What I do not know is: Are this things that already exist - in which 
> case I would be happy if somebody could tell me how to find them! -, 
> or are these functions rather "feature requests"?
>
> In fact I can hardly believe that I am the first with such kind of 
> dreams, so my hope is still that they already exist somewhere...
>
> --
> Cornelis Bockem?hl
> mail: cornelis at bockemuehl.ch
> phone: +41 79 644 9943
> Basel, Switzerland
> https://cobo.bockemuehl.ch
> <https://cobo.bockemuehl.ch>
>
>
-- 

*Dr. Eric D?nges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doenges at mvtec.com <mailto:mustermann at mvtec.com> | Tel: +49 89 457 695-0 
| www.mvtec.com <http://www.mvtec.com>

Find our privacy policy here <https://www.mvtec.com/imprint>.

Sign up <https://www.mvtec.com/newsletter> for our MVTec Newsletter!

Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht M?nchen HRB 114695

MVTec Software GmbH Logo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190920/b8d5155a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6210-5D84CB00-C5-12967640
Type: image/png
Size: 16631 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190920/b8d5155a/attachment-0001.png>

From sachiwee at gmail.com  Fri Sep 20 13:22:52 2019
From: sachiwee at gmail.com (Sachithra Weerasooriya)
Date: Fri, 20 Sep 2019 12:22:52 -0500
Subject: [CMake] Linking GSL to CMake
Message-ID: <CAO9qim+gN-haxpBwDgJqW2qsbZfS=Xr5ykDrhtB13hNDOP=23w@mail.gmail.com>

Hello!
Could you please let me know how to link GSL to CMake using command line in
a MAC? In my case GSL is not installed in a standard path. So make cannot
find gal header files.

Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190920/eeb7a096/attachment.html>

From cornelis at bockemuehl.ch  Sun Sep 22 10:47:30 2019
From: cornelis at bockemuehl.ch (=?utf-8?q?Cornelis_Bockem=C3=BChl?=)
Date: Sun, 22 Sep 2019 16:47:30 +0200
Subject: [CMake] 
 =?utf-8?q?=3F=3D=3D=3Futf-8=3Fq=3F__Debug_logging_of_ite?=
 =?utf-8?q?ms?=
In-Reply-To: <92312bde-b740-1b7b-47ff-fa9f91ee3bbb@mvtec.com>
Message-ID: <62a4-5d878980-b-69a20b00@103821873>


Hi Eric,

Thanks for the hint regarding dumping variables: That's good to know!

However, I was learning that working with CMake is in may ways a question of adopting some "good practice", but it is not really being enforced by the language. One of the things that are for me part of this good practice would be to deal with targets and their dependencies, and properties. Which means a certain degree of modularity in the sense that you can easily plug projects together by just referring to targets, like by calling find_package().

But again: You will never easily know what a package is actually giving you - without investing hours and days of code reading - and maybe not even then!

But calling some "dump_targets" function after "find_package" (or also before and after - for comparison) would give you a chance to know the effect of endless "code deserts" with one line of code.

And because this is so fundamental in my eyes, I still almost assume that also for targets and properties there must be some function available - which I simply have not found yet!??

Or else I would consider this an urgent feature request!

Best regards,
Cornelis


Am Freitag, September 20, 2019 15:07 CEST, Eric Doenges <doenges at mvtec.com> schrieb:
??
I don't know about the targets, but you can get all variables currently defined for a directory by reading the VARIABLES property, e.g.
get_property(_variables DIRECTORY "${CMAKE_SOURCE_DIR}" PROPERTY VARIABLES)
I use this to dump the variables into a file so I can see with which variable settings my build directory was configured with.
With kind regards,
EricAm 20.09.19 um 14:49 schrieb Cornelis Bockem?hl:
Right now I am fighting my way through large amounts of CMake code (actually working on a ParaView custom application with many own plugins, views, domains, property widgets etc. etc.), and it is sometimes really not easy not to lose track completely! Sometimes I am happy to be back into complex C++ programming - because I see much more logic in the entire thing. And it is of course no news that CMake code is not famous for being easy to debug.

Anyway, I am dreaming of some "simple" features that would sometimes help a lot, and it is all about "dumping" some kind of data. Actually this is for me often also the favorite way to debug C++ code: just print out the values of variables, arrays, etc. - e.g. if setting a breakpoint in the debugger is difficult because you are interested only in the 928773th occurrence of a certain piece of code (without even knowing that number...).

Accordingly in CMake code I am working a lot with the message() function - but within that code the problem is often that you do not even know which variables would be available at all!

Thus functions like would be really great to have:

??? ?give me a list of all currently known targets?
??? ?give me a list of all properties of a target?
??? ?give me a list of all currently defined variables?
??? etc.

What I do not know is: Are this things that already exist - in which case I would be happy if somebody could tell me how to find them! -, or are these functions rather "feature requests"?

In fact I can hardly believe that I am the first with such kind of dreams, so my hope is still that they already exist somewhere...--
Dr. Eric D?nges
Senior Software Engineer
MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doenges at mvtec.com | Tel: +49 89 457 695-0 | www.mvtec.com
Find our privacy policy here.
?Sign up for our MVTec Newsletter!
Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht M?nchen HRB 114695
?
--
Cornelis Bockem?hl
mail: cornelis at bockemuehl.ch
phone: +41 79 644 9943
Basel, Switzerland
https://cobo.bockemuehl.ch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190922/56bd57cf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 62A4-5D878980-D-69A20B00
Type: image/png
Size: 16631 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190922/56bd57cf/attachment-0001.png>

From craig.scott at crascit.com  Sun Sep 22 15:46:31 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Mon, 23 Sep 2019 05:46:31 +1000
Subject: [CMake] ?==?utf-8?q? Debug logging of items
In-Reply-To: <62a4-5d878980-b-69a20b00@103821873>
References: <92312bde-b740-1b7b-47ff-fa9f91ee3bbb@mvtec.com>
 <62a4-5d878980-b-69a20b00@103821873>
Message-ID: <CA+dygY=r27sBF6-7Y8tHkS3DV78YqiMj+K8dDciDvwfCeun2Vw@mail.gmail.com>

You may want to take a look at the BUILDSYSTEM_TARGETS
<https://cmake.org/cmake/help/latest/prop_dir/BUILDSYSTEM_TARGETS.html>
directory property. It might not be quite what you're looking for, but it
might be close enough. I'm not aware of any way to get a list of all
defined properties on a given target though.


On Mon, Sep 23, 2019 at 12:47 AM Cornelis Bockem?hl <cornelis at bockemuehl.ch>
wrote:

> Hi Eric,
>
> Thanks for the hint regarding dumping variables: That's good to know!
>
> However, I was learning that working with CMake is in may ways a question
> of adopting some "good practice", but it is not really being enforced by
> the language. One of the things that are for me part of this good practice
> would be to deal with targets and their dependencies, and properties. Which
> means a certain degree of modularity in the sense that you can easily plug
> projects together by just referring to targets, like by calling
> find_package().
>
> But again: You will never easily know what a package is actually giving
> you - without investing hours and days of code reading - and maybe not even
> then!
>
> But calling some "dump_targets" function after "find_package" (or also
> before and after - for comparison) would give you a chance to know the
> effect of endless "code deserts" with one line of code.
>
> And because this is so fundamental in my eyes, I still almost assume that
> also for targets and properties there must be some function available -
> which I simply have not found yet!??
>
> Or else I would consider this an urgent feature request!
>
> Best regards,
> Cornelis
>
>
> Am Freitag, September 20, 2019 15:07 CEST, Eric Doenges <doenges at mvtec.com>
> schrieb:
>
>
>
>
> I don't know about the targets, but you can get all variables currently
> defined for a directory by reading the VARIABLES property, e.g.
>
> get_property(_variables DIRECTORY "${CMAKE_SOURCE_DIR}" PROPERTY VARIABLES)
>
> I use this to dump the variables into a file so I can see with which
> variable settings my build directory was configured with.
>
> With kind regards,
> Eric
> Am 20.09.19 um 14:49 schrieb Cornelis Bockem?hl:
>
> Right now I am fighting my way through large amounts of CMake code
> (actually working on a ParaView custom application with many own plugins,
> views, domains, property widgets etc. etc.), and it is sometimes really not
> easy not to lose track completely! Sometimes I am happy to be back into
> complex C++ programming - because I see much more logic in the entire
> thing. And it is of course no news that CMake code is not famous for being
> easy to debug.
>
> Anyway, I am dreaming of some "simple" features that would sometimes help
> a lot, and it is all about "dumping" some kind of data. Actually this is
> for me often also the favorite way to debug C++ code: just print out the
> values of variables, arrays, etc. - e.g. if setting a breakpoint in the
> debugger is difficult because you are interested only in the 928773th
> occurrence of a certain piece of code (without even knowing that number...).
>
> Accordingly in CMake code I am working a lot with the message() function -
> but within that code the problem is often that you do not even know which
> variables would be available at all!
>
> Thus functions like would be really great to have:
>
>     ?give me a list of all currently known targets?
>     ?give me a list of all properties of a target?
>     ?give me a list of all currently defined variables?
>     etc.
>
> What I do not know is: Are this things that already exist - in which case
> I would be happy if somebody could tell me how to find them! -, or are
> these functions rather "feature requests"?
>
> In fact I can hardly believe that I am the first with such kind of dreams,
> so my hope is still that they already exist somewhere...
>
>

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
Consulting services (CMake, C++, build/release processes):
https://crascit.com/services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190923/46f5a3f8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 62A4-5D878980-D-69A20B00
Type: image/png
Size: 16631 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190923/46f5a3f8/attachment-0001.png>

From cornelis at bockemuehl.ch  Mon Sep 23 02:50:23 2019
From: cornelis at bockemuehl.ch (=?utf-8?q?Cornelis_Bockem=C3=BChl?=)
Date: Mon, 23 Sep 2019 08:50:23 +0200
Subject: [CMake] 
 =?utf-8?b?Pz09P3V0Zi04P3E/ID89PT91dGYtOD9xPyA/PSBEZWJ1?=
 =?utf-8?q?g_logging_of_item?=
In-Reply-To: <CA+dygY=r27sBF6-7Y8tHkS3DV78YqiMj+K8dDciDvwfCeun2Vw@mail.gmail.com>
Message-ID: <62a4-5d886b00-13-69a20b00@103821876>


Thanks for the hint: This may indeed help for some situations!

But explicitly not in the most important case because it explicitly says "The list does not include any Imported Targets or Alias Targets, but does include Interface Libraries." Well, these would of course be the most important target types - like after a find_package().

I conclude from your answer (and the previous one) that indeed the thing that I am looking for does currently NOT exist! So I may try to launch it as a "feature request" - because I cannot believe that I am the only one who gets lost in this field.

On the other hand I can also not believe that it can be too difficult to implement: The interpreter can always tell me if a target_link_libraries(...) is referring to an "unknown target" - so why not have a function that simply tells me which targets are known - including ALL possible targets?

I like many of the automatisms that CMake is offering, but like with all automatisms: If things do not work as expected you need a way to find out what the problem is - and plain guessing is only an option for really trivial cases! But even there it is only second choice if the software could just as well tell you exactly what the problem is...

Best regards,
Cornelis

Am Sonntag, September 22, 2019 21:46 CEST, Craig Scott <craig.scott at crascit.com> schrieb:
?You may want to take a look at the BUILDSYSTEM_TARGETS directory property. It might not be quite what you're looking for, but it might be close enough. I'm not aware of any way to get a list of all defined properties on a given target though.??On Mon, Sep 23, 2019 at 12:47 AM Cornelis Bockem?hl <cornelis at bockemuehl.ch> wrote:
Hi Eric,

Thanks for the hint regarding dumping variables: That's good to know!

However, I was learning that working with CMake is in may ways a question of adopting some "good practice", but it is not really being enforced by the language. One of the things that are for me part of this good practice would be to deal with targets and their dependencies, and properties. Which means a certain degree of modularity in the sense that you can easily plug projects together by just referring to targets, like by calling find_package().

But again: You will never easily know what a package is actually giving you - without investing hours and days of code reading - and maybe not even then!

But calling some "dump_targets" function after "find_package" (or also before and after - for comparison) would give you a chance to know the effect of endless "code deserts" with one line of code.

And because this is so fundamental in my eyes, I still almost assume that also for targets and properties there must be some function available - which I simply have not found yet!??

Or else I would consider this an urgent feature request!

Best regards,
Cornelis


Am Freitag, September 20, 2019 15:07 CEST, Eric Doenges <doenges at mvtec.com> schrieb:
??
I don't know about the targets, but you can get all variables currently defined for a directory by reading the VARIABLES property, e.g.
get_property(_variables DIRECTORY "${CMAKE_SOURCE_DIR}" PROPERTY VARIABLES)
I use this to dump the variables into a file so I can see with which variable settings my build directory was configured with.
With kind regards,
EricAm 20.09.19 um 14:49 schrieb Cornelis Bockem?hl:
Right now I am fighting my way through large amounts of CMake code (actually working on a ParaView custom application with many own plugins, views, domains, property widgets etc. etc.), and it is sometimes really not easy not to lose track completely! Sometimes I am happy to be back into complex C++ programming - because I see much more logic in the entire thing. And it is of course no news that CMake code is not famous for being easy to debug.

Anyway, I am dreaming of some "simple" features that would sometimes help a lot, and it is all about "dumping" some kind of data. Actually this is for me often also the favorite way to debug C++ code: just print out the values of variables, arrays, etc. - e.g. if setting a breakpoint in the debugger is difficult because you are interested only in the 928773th occurrence of a certain piece of code (without even knowing that number...).

Accordingly in CMake code I am working a lot with the message() function - but within that code the problem is often that you do not even know which variables would be available at all!

Thus functions like would be really great to have:

??? ?give me a list of all currently known targets?
??? ?give me a list of all properties of a target?
??? ?give me a list of all currently defined variables?
??? etc.

What I do not know is: Are this things that already exist - in which case I would be happy if somebody could tell me how to find them! -, or are these functions rather "feature requests"?

In fact I can hardly believe that I am the first with such kind of dreams, so my hope is still that they already exist somewhere...??--Craig ScottMelbourne, Australiahttps://crascit.com?Get the hand-book for every CMake user:?Professional CMake: A Practical GuideConsulting services (CMake, C++, build/release processes): https://crascit.com/services
--
Cornelis Bockem?hl
mail: cornelis at bockemuehl.ch
phone: +41 79 644 9943
Basel, Switzerland
https://cobo.bockemuehl.ch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190923/91c82429/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 62A4-5D886B00-15-69A20B00
Type: image/png
Size: 16631 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190923/91c82429/attachment-0001.png>

From bradbell at seanet.com  Mon Sep 23 09:05:50 2019
From: bradbell at seanet.com (Brad Bell)
Date: Mon, 23 Sep 2019 06:05:50 -0700
Subject: [CMake] FindBoost Warnings
Message-ID: <0e6b33dc-73bd-a50b-eff4-e38a9baa16e5@seanet.com>

I am using FindBoost in a cmake script
to determine if certain components of the boost package are available on the target system.

If so, the script builds examples that use my package with boost.
If not, these example are not built and tested.

When the target system does not have boost, the user gets the warning:

CMake Warning at /usr/share/cmake-3.10/Modules/FindBoost.cmake:567 (message):
 ? Imported targets and dependency information not available for Boost version
 ? (all versions older than 1.33)
Call Stack (most recent call first):
 ? /usr/share/cmake-3.10/Modules/FindBoost.cmake:907 (_Boost_COMPONENT_DEPENDENCIES)
 ? /usr/share/cmake-3.10/Modules/FindBoost.cmake:1558 (_Boost_MISSING_DEPENDENCIES)
 ? CMakeLists.txt:245 (FIND_PACKAGE)

This is not a problem because if the user's system does not have boost,
they will no be using the case that the examples cover.

How do I suppress this warning ?

From rleigh at codelibre.net  Mon Sep 23 09:14:50 2019
From: rleigh at codelibre.net (Roger Leigh)
Date: Mon, 23 Sep 2019 14:14:50 +0100
Subject: [CMake] FindBoost Warnings
In-Reply-To: <0e6b33dc-73bd-a50b-eff4-e38a9baa16e5@seanet.com>
References: <0e6b33dc-73bd-a50b-eff4-e38a9baa16e5@seanet.com>
Message-ID: <ed9749d4-74d4-3b4d-8779-b230730a5310@codelibre.net>

On 23/09/2019 14:05, Brad Bell wrote:

> When the target system does not have boost, the user gets the warning:
>
> CMake Warning at /usr/share/cmake-3.10/Modules/FindBoost.cmake:567 
> (message):
> ? Imported targets and dependency information not available for Boost 
> version
> ? (all versions older than 1.33)
> Call Stack (most recent call first):
> ? /usr/share/cmake-3.10/Modules/FindBoost.cmake:907 
> (_Boost_COMPONENT_DEPENDENCIES)
> ? /usr/share/cmake-3.10/Modules/FindBoost.cmake:1558 
> (_Boost_MISSING_DEPENDENCIES)
> ? CMakeLists.txt:245 (FIND_PACKAGE)
>
> This is not a problem because if the user's system does not have boost,
> they will no be using the case that the examples cover.
>
> How do I suppress this warning ?

I think it's already fixed in more recent CMake versions.? It now only 
prints that message when Boost is found, and older than 1.33.


Regards,

Roger


From imriska at photoneo.com  Mon Sep 23 10:24:44 2019
From: imriska at photoneo.com (Jakub Imriska)
Date: Mon, 23 Sep 2019 16:24:44 +0200
Subject: [CMake] Undocumented change of behavior when using EXCLUDE_FROM_ALL
Message-ID: <CACm6=inoBJLV3OZUFzHAr+cO=7pVbXXuxQBCzfMBOz7ABpp2Aw@mail.gmail.com>

Hi CMake community,

the option EXCLUDE_FROM_ALL
<https://cmake.org/cmake/help/v3.14/prop_dir/EXCLUDE_FROM_ALL.html?highlight=exclude_from_all>
of *add_subdirectory* command affects in CMake 3.14.3 the content of the
Visual Studio solution file in the added subdirectory.
The difference is subtle: if the subdirectory A added with EXCLUDE_FROM_ALL
from source root contains another subdirectory B, a solution file in A
does *not
contain* project from B.
The behavior changed between versions 3.13.5 and 3.14.3. Tested also on
3.15.0, which produces same output as 3.14.3.Observed on Win 10 using *Visual
Studio 16 2019* and *Visual Studio 12 2013 Win64 *generators.
Test with *CodeBlocks - Unix Makefiles *generator does not show this issue.

Is there a way to retain the old behavior?
Thanks for an advice.

-------------------------------------------------------------------
Minimal example (attached):

$ cat CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(main)
add_subdirectory(subdir EXCLUDE_FROM_ALL)

$ cat subdir/CMakeLists.txt
project(utilities)
add_subdirectory(subsubdir)

$ cat subdir/subsubdir/CMakeLists.txt
project(util)
add_executable(util util.cpp)

With CMake 3.13.5 the utilities solution file contains project util,
whereas with CMake 3.14.3 or 3.15.0 it does not.

--

Jakub Imri?ka

*Programmer and research developer*, Photoneo s. r. o. - Focused on 3D

-- 
Meet us:
CIIF <http://www.ciif-expo.com/en/>, IAS 
<http://www.industrial-automation-show.com/>, booth #C010, Hall 8.1 H, 
17-21 September 2019, Shanghai (CN)
MOTEK <https://www.motek-messe.de/en>, 
booth ?#7513, Hall 7, ?7-10 October 2019, Stuttgart (DE)
International 
Engineering Fair Brno 2019 <https://www.bvv.cz/en/msv/>, ABB booth #093, 
Hall P, 7-11 October 2019, Brno (CZ)??


CRAV.ai 
<https://www.robotics.org/collaborative-robots-advanced-vision-and-ai-conference>, 
tabletop 3, 12-13 November 2019, San Jose (CA)

SPS IPC Drives 
<https://sps.mesago.com/events/en.html?ovs_force_web=1&sid=3db8da8e0409fc89fd1c3b914c44be78&stamp=1541992980>, 
booth #202, Hall 8, 26-28 November 2019, Nuremberg (DE)?





---


This 
e-mail was sent by Photoneo s.r.o. and may contain confidential and/or 
proprietary information. If you are not the intended addressee, please 
inform the sender immediately and delete this e-mail.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190923/ba66eee5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMake_EXCLUDE_FROM_ALL_example.zip
Type: application/x-zip-compressed
Size: 1308 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190923/ba66eee5/attachment.bin>

From Ksenofon_Konomi at uml.edu  Mon Sep 23 17:58:29 2019
From: Ksenofon_Konomi at uml.edu (Konomi, Ksenofon)
Date: Mon, 23 Sep 2019 21:58:29 +0000
Subject: [CMake] New to cmake, need help with FindMPI.cmake
Message-ID: <dc61d2c3c884474ebee9803f74101f2d@uml.edu>

Hello Everyone,

I am new to cmake and I need help using the FindMPI.cmake module. I am using windows 7, and I have Visual Studios 2019 installed. I got the cmakelists.txt file to work and generated an output with various files but I have no clue what to do now, or if its even if I got the cmakelists.txt file set up properly.  I have attached the cmakelists.txt file I have been using. I appreciate your help and guidance.

Thank You!

Ksenofon Konomi
Radiation Physicist
University of Massachusetts Lowell
Radiation Lab
Office: (978) 934-2749


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190923/2c316da1/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CMakeLists.txt
URL: <https://cmake.org/pipermail/cmake/attachments/20190923/2c316da1/attachment.txt>

From Felix.Ramold at kuka.com  Tue Sep 24 08:16:58 2019
From: Felix.Ramold at kuka.com (FRamold)
Date: Tue, 24 Sep 2019 05:16:58 -0700 (MST)
Subject: [CMake] Return an Error Code (or something) from a CMake Script.
In-Reply-To: <C97F5CB9-496A-4012-AC55-9071635E8A41@bluequartz.net>
References: <C97F5CB9-496A-4012-AC55-9071635E8A41@bluequartz.net>
Message-ID: <1569327418705-0.post@n2.nabble.com>

Hi Michael,

you probably figured this out by now, but for future reference: You have to
log to stderr to make the script fail.

This example works (as in /does not build/ ;) ):

    file(GENERATE OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/skript.cmake"
       CONTENT "message(FATAL_ERROR \"Script failed!!\")"
    )
    add_custom_target(runSkript
       COMMAND ${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/skript.cmake
    )

btw: Using CMake 3.10

Greetings,
Felix



--
Sent from: http://cmake.3232098.n2.nabble.com/

From hex7c3 at gmail.com  Tue Sep 24 09:23:52 2019
From: hex7c3 at gmail.com (hex)
Date: Tue, 24 Sep 2019 14:23:52 +0100
Subject: [CMake] file dependency not working in external projects
Message-ID: <6e50496c-706c-a037-fc54-3f1880a86cf4@gmail.com>

hello,

I have a problem with a build step.

The following command is run every time somefile changes:

add_custom_command( OUTPUT out.put
 ??? COMMAND touch out.put
 ??? DEPENDS somefile.txt
)

add_custom_target( sometarget DEPENDS out.put )


I move this snippet inside an external project (with 
ExternalProject_Add) and the custom command is only run once at build.

I am using absolute path to somefile, the command is not rebuild 
changing somefile.

I am using Gnu make generator and build with make all


What am I missing?


From brad.king at kitware.com  Tue Sep 24 09:39:48 2019
From: brad.king at kitware.com (Brad King)
Date: Tue, 24 Sep 2019 09:39:48 -0400
Subject: [CMake] Undocumented change of behavior when using
 EXCLUDE_FROM_ALL
In-Reply-To: <CACm6=inoBJLV3OZUFzHAr+cO=7pVbXXuxQBCzfMBOz7ABpp2Aw@mail.gmail.com>
References: <CACm6=inoBJLV3OZUFzHAr+cO=7pVbXXuxQBCzfMBOz7ABpp2Aw@mail.gmail.com>
Message-ID: <a032e6ef-139f-69b0-29fa-c3c271ed34f4@kitware.com>

On 9/23/19 10:24 AM, Jakub Imriska wrote:
> Is there a way to retain the old behavior?

We thought the change was backward compatible with existing projects but perhaps not.
I've opened an issue:

  https://gitlab.kitware.com/cmake/cmake/issues/19753

Thanks,
-Brad

From doenges at mvtec.com  Tue Sep 24 09:59:50 2019
From: doenges at mvtec.com (Eric Doenges)
Date: Tue, 24 Sep 2019 15:59:50 +0200
Subject: [CMake] file dependency not working in external projects
In-Reply-To: <6e50496c-706c-a037-fc54-3f1880a86cf4@gmail.com>
References: <6e50496c-706c-a037-fc54-3f1880a86cf4@gmail.com>
Message-ID: <533cf7a4-2d0e-38c8-9aa8-840cd05685d3@mvtec.com>

You're probably missing the BUILD_ALWAYS option to ExternalProject_Add:

|BUILD_ALWAYS <bool>|
    Enabling this option forces the build step to always be run. This
    can be the easiest way to robustly ensure that the external
    project?s own build dependencies are evaluated rather than relying
    on the default success timestamp-based method. This option is not
    normally needed unless developers are expected to modify something
    the external project?s build depends on in a way that is not
    detectable via the step target dependencies (e.g. |SOURCE_DIR| is
    used without a download method and developers might modify the
    sources in |SOURCE_DIR|).

Am 24.09.19 um 15:23 schrieb hex:
> hello,
>
> I have a problem with a build step.
>
> The following command is run every time somefile changes:
>
> add_custom_command( OUTPUT out.put
> ??? COMMAND touch out.put
> ??? DEPENDS somefile.txt
> )
>
> add_custom_target( sometarget DEPENDS out.put )
>
>
> I move this snippet inside an external project (with 
> ExternalProject_Add) and the custom command is only run once at build.
>
> I am using absolute path to somefile, the command is not rebuild 
> changing somefile.
>
> I am using Gnu make generator and build with make all
>
>
> What am I missing?
>
-- 

*Dr. Eric D?nges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doenges at mvtec.com <mailto:mustermann at mvtec.com> | Tel: +49 89 457 695-0 
| www.mvtec.com <http://www.mvtec.com>

Find our privacy policy here <https://www.mvtec.com/imprint>.

Sign up <https://www.mvtec.com/newsletter> for our MVTec Newsletter!

Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht M?nchen HRB 114695

MVTec Software GmbH Logo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190924/d51785be/attachment-0001.html>

From hex7c3 at gmail.com  Tue Sep 24 10:07:34 2019
From: hex7c3 at gmail.com (hex)
Date: Tue, 24 Sep 2019 15:07:34 +0100
Subject: [CMake] file dependency not working in external projects
In-Reply-To: <569f5110-64ff-1ee8-0102-ff0f04dbda0b@gmail.com>
References: <569f5110-64ff-1ee8-0102-ff0f04dbda0b@gmail.com>
Message-ID: <fa25744c-c4e1-d3b3-32ae-b322c1fcf6d1@gmail.com>


hello Eric Doenges,

You are correct. This has been given me headaches.

Setting BUILD_ALWAYS to TRUE gives the desired behaviour.


Thank you


On 24/09/2019 14:59, Eric Doenges wrote:
>
> You're probably missing the BUILD_ALWAYS option to ExternalProject_Add:
>
> |BUILD_ALWAYS <bool>|
>     Enabling this option forces the build step to always be run. This
>     can be the easiest way to robustly ensure that the external
>     project?s own build dependencies are evaluated rather than relying
>     on the default success timestamp-based method. This option is not
>     normally needed unless developers are expected to modify something
>     the external project?s build depends on in a way that is not
>     detectable via the step target dependencies (e.g. |SOURCE_DIR| is
>     used without a download method and developers might modify the
>     sources in |SOURCE_DIR|).
> Am 24.09.19 um 15:23 schrieb hex:
>> hello,
>>
>> I have a problem with a build step.
>>
>> The following command is run every time somefile changes:
>>
>> add_custom_command( OUTPUT out.put
>> ??? COMMAND touch out.put
>> ??? DEPENDS somefile.txt
>> )
>>
>> add_custom_target( sometarget DEPENDS out.put )
>>
>>
>> I move this snippet inside an external project (with 
>> ExternalProject_Add) and the custom command is only run once at build.
>>
>> I am using absolute path to somefile, the command is not rebuild 
>> changing somefile.
>>
>> I am using Gnu make generator and build with make all
>>
>>
>> What am I missing?
>>
> -- 
>
> *Dr. Eric D?nges*
> Senior Software Engineer
>
> MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
> doenges at mvtec.com <mailto:mustermann at mvtec.com> | Tel: +49 89 457 
> 695-0 | www.mvtec.com <http://www.mvtec.com>
>
> Find our privacy policy here <https://www.mvtec.com/imprint>.
>
> Sign up <https://www.mvtec.com/newsletter> for our MVTec Newsletter!
>
> Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
> Amtsgericht M?nchen HRB 114695
>
> MVTec Software GmbH Logo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190924/20874494/attachment.html>

From imriska at photoneo.com  Tue Sep 24 11:00:28 2019
From: imriska at photoneo.com (Jakub Imriska)
Date: Tue, 24 Sep 2019 17:00:28 +0200
Subject: [CMake] Undocumented change of behavior when using
 EXCLUDE_FROM_ALL
In-Reply-To: <a032e6ef-139f-69b0-29fa-c3c271ed34f4@kitware.com>
References: <CACm6=inoBJLV3OZUFzHAr+cO=7pVbXXuxQBCzfMBOz7ABpp2Aw@mail.gmail.com>
 <a032e6ef-139f-69b0-29fa-c3c271ed34f4@kitware.com>
Message-ID: <CACm6=inW20Cc_9igGgo-2PbddnusfAP-c_i1ZqBdcCNx=hp=Sg@mail.gmail.com>

Thanks for letting me know.

--

Jakub Imri?ka

*Programmer and research developer*, Photoneo s. r. o. - Focused on 3D

-- 
Meet us:
CIIF <http://www.ciif-expo.com/en/>, IAS 
<http://www.industrial-automation-show.com/>, booth #C010, Hall 8.1 H, 
17-21 September 2019, Shanghai (CN)
MOTEK <https://www.motek-messe.de/en>, 
booth ?#7513, Hall 7, ?7-10 October 2019, Stuttgart (DE)
International 
Engineering Fair Brno 2019 <https://www.bvv.cz/en/msv/>, ABB booth #093, 
Hall P, 7-11 October 2019, Brno (CZ)??


CRAV.ai 
<https://www.robotics.org/collaborative-robots-advanced-vision-and-ai-conference>, 
tabletop 3, 12-13 November 2019, San Jose (CA)

SPS IPC Drives 
<https://sps.mesago.com/events/en.html?ovs_force_web=1&sid=3db8da8e0409fc89fd1c3b914c44be78&stamp=1541992980>, 
booth #202, Hall 8, 26-28 November 2019, Nuremberg (DE)?





---


This 
e-mail was sent by Photoneo s.r.o. and may contain confidential and/or 
proprietary information. If you are not the intended addressee, please 
inform the sender immediately and delete this e-mail.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190924/013d77ad/attachment.html>

From bradbell at seanet.com  Tue Sep 24 11:51:12 2019
From: bradbell at seanet.com (Brad Bell)
Date: Tue, 24 Sep 2019 08:51:12 -0700
Subject: [CMake] FindBoost Warnings
In-Reply-To: <ed9749d4-74d4-3b4d-8779-b230730a5310@codelibre.net>
References: <0e6b33dc-73bd-a50b-eff4-e38a9baa16e5@seanet.com>
 <ed9749d4-74d4-3b4d-8779-b230730a5310@codelibre.net>
Message-ID: <b2c586cc-d13c-c413-4d88-df964f09d5b5@seanet.com>

CMake version 3.10.2 seems to have the problem and it seems to be fixed in 3.13.4.

Thanks

On 9/23/19 6:14 AM, Roger Leigh wrote:
> On 23/09/2019 14:05, Brad Bell wrote:
>
>> When the target system does not have boost, the user gets the warning:
>>
>> CMake Warning at /usr/share/cmake-3.10/Modules/FindBoost.cmake:567 (message):
>> ? Imported targets and dependency information not available for Boost version
>> ? (all versions older than 1.33)
>> Call Stack (most recent call first):
>> ? /usr/share/cmake-3.10/Modules/FindBoost.cmake:907 (_Boost_COMPONENT_DEPENDENCIES)
>> ? /usr/share/cmake-3.10/Modules/FindBoost.cmake:1558 (_Boost_MISSING_DEPENDENCIES)
>> ? CMakeLists.txt:245 (FIND_PACKAGE)
>>
>> This is not a problem because if the user's system does not have boost,
>> they will no be using the case that the examples cover.
>>
>> How do I suppress this warning ?
>
> I think it's already fixed in more recent CMake versions.? It now only prints that message when 
> Boost is found, and older than 1.33.
>
>
> Regards,
>
> Roger
>
>


From mwd at cert.org  Tue Sep 24 12:02:00 2019
From: mwd at cert.org (Michael Welsh Duggan)
Date: Tue, 24 Sep 2019 12:02:00 -0400
Subject: [CMake] MacOS and shared libraries from imported targets
Message-ID: <y2tdef8sqdfzt3.fsf@lx-birch.ad.sei.cmu.edu>

I have a project that links against an external dynamic library for
which I have written a Find module that creates an import target.  I do
this, in part, by setting the IMPORTED_LOCATION property of the target
to the location of the dynamic library.

Unfortunately, on OSX the library shows up in the executable load
commands as an LC_LOAD_DYLIB of the raw filename (no directory) of the
shared library.  I expected it to use the whole path.  I tried setting
the INSTALL_NAME_DIR property to the directory containing the shared
library, but this changed nothing.

I will note that this is all still in the build location, as opposed to
post-install.  I am using the following settings currently:

set(CMAKE_SKIP_BUILD_RPATH false)
set(CMAKE_BUILD_WITH_INSTALL_RPATH false)
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH true)
set(CMAKE_MACOSX_RPATH true)

I'm not 100% confident with how these options interact, so I am more
than prepared for someone to tell me that I am doing something wrong.
Any hints would be appreciated.

-- 
Michael Welsh Duggan
(mwd at cert.org)

From sachiwee at gmail.com  Tue Sep 24 12:22:35 2019
From: sachiwee at gmail.com (Sachithra Weerasooriya)
Date: Tue, 24 Sep 2019 11:22:35 -0500
Subject: [CMake] Linking GSL to cmake using command line
Message-ID: <27438CB7-E121-4E39-B17A-8040A385D5D8@gmail.com>

Hi CMake community!
I am having trouble linking GSL to cmake using command line. I am using a Mac. Can someone please help me?

Thank you!
Best regards,
Sachi



From rwan.work at gmail.com  Tue Sep 24 12:28:15 2019
From: rwan.work at gmail.com (Raymond Wan)
Date: Wed, 25 Sep 2019 00:28:15 +0800
Subject: [CMake] Linking GSL to cmake using command line
In-Reply-To: <27438CB7-E121-4E39-B17A-8040A385D5D8@gmail.com>
References: <27438CB7-E121-4E39-B17A-8040A385D5D8@gmail.com>
Message-ID: <CAH8UK3W4bg1Rs-6WJd_6Yv5o4oUodJZAPHd+bPbhicpwppTy8w@mail.gmail.com>

Hi Sachi,

Unfortunately, the short answer is "no".  I think you misunderstand
what CMake is.  One way to summarise it is that it allows developers
of programs to describe/explain how to compile and link software.  For
example, suppose there is a program X and it uses the GSL library.  A
programmer might use CMake to explain how GSL can link with X on Mac,
Linux, etc. -- across various platforms.  This will make it easier for
the end user.

If you are an end user (i.e., you didn't make the program X), then you
need CMake isn't for you.  I'm afraid you might have to read the GSL
documentation for Mac, instead.  If you are the developer of X, then
you might want to go through the various CMake tutorials and give it a
try -- then, if you're still stuck, post what you got so far so that
someone can help you.

Based on what you've asked, my guess is that CMake isn't what you
should be looking into.

Ray

On Wed, Sep 25, 2019 at 12:22 AM Sachithra Weerasooriya
<sachiwee at gmail.com> wrote:
>
> Hi CMake community!
> I am having trouble linking GSL to cmake using command line. I am using a Mac. Can someone please help me?
>
> Thank you!
> Best regards,
> Sachi
>
>
> --
>
> 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 services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From rwan.work at gmail.com  Tue Sep 24 12:55:14 2019
From: rwan.work at gmail.com (Raymond Wan)
Date: Wed, 25 Sep 2019 00:55:14 +0800
Subject: [CMake] Fwd:  Linking GSL to cmake using command line
In-Reply-To: <CAH8UK3UshEkxFWSh9m+qVm=0_qbtDLHvDTfT4bSz6Oo37xdL0g@mail.gmail.com>
References: <27438CB7-E121-4E39-B17A-8040A385D5D8@gmail.com>
 <CAH8UK3W4bg1Rs-6WJd_6Yv5o4oUodJZAPHd+bPbhicpwppTy8w@mail.gmail.com>
 <EF43F230-CF6B-4AF6-BE93-10717F7BFBA2@gmail.com>
 <CAH8UK3UshEkxFWSh9m+qVm=0_qbtDLHvDTfT4bSz6Oo37xdL0g@mail.gmail.com>
Message-ID: <CAH8UK3UGYzKxiGinNXArmH13oscO-a7WvpGbPmUF9v4_q+F8Cg@mail.gmail.com>

Hi Sachi and everyone,

Sorry, I didn't realise her original message wasn't CC'ed to the list.
Please keep replies to the list, Sachi, unless there's a good reason
you shouldn't.  It will also allow someone to jump in if I've said
something incorrectly about your problem.

Ray


---------- Forwarded message ---------
From: Raymond Wan <rwan.work at gmail.com>
Date: Wed, Sep 25, 2019 at 12:52 AM
Subject: Re: [CMake] Linking GSL to cmake using command line
To: Sachithra Weerasooriya <sachiwee at gmail.com>


Hi Sachi,

Then, to be frank, it's not something that CMake's users can help you
with.  It's (most probably) how the developer is using CMake to look
for GSL and you should be contacting him/her.  Generally, the end user
of program X shouldn't have to learn about CMake.  (Of course, no one
is stopping you from learning.)  The developer should be trying to fix
it, unless you happen to already be an expert on CMake.

If the developer isn't very responsive to your query, then that's a
separate issue, that's also not related to CMake...  S/he might be
happy to hear from you since it's a bug report and it can only make
program X better...I think?

Ray

On Wed, Sep 25, 2019 at 12:38 AM Sachithra Weerasooriya
<sachiwee at gmail.com> wrote:
>
> Hi Ray!
> Thank you  for your prompt reply! I appreciate it. Actually I am trying to install a package that uses cmake. Although GSL is installed in my machine, cmake can?t find the GSL directory.
>
> Best regards,
> Sachi
>
>
>
> Sent from my iPhone
>
> > On Sep 24, 2019, at 11:28 AM, Raymond Wan <rwan.work at gmail.com> wrote:
> >
> > Hi Sachi,
> >
> > Unfortunately, the short answer is "no".  I think you misunderstand
> > what CMake is.  One way to summarise it is that it allows developers
> > of programs to describe/explain how to compile and link software.  For
> > example, suppose there is a program X and it uses the GSL library.  A
> > programmer might use CMake to explain how GSL can link with X on Mac,
> > Linux, etc. -- across various platforms.  This will make it easier for
> > the end user.
> >
> > If you are an end user (i.e., you didn't make the program X), then you
> > need CMake isn't for you.  I'm afraid you might have to read the GSL
> > documentation for Mac, instead.  If you are the developer of X, then
> > you might want to go through the various CMake tutorials and give it a
> > try -- then, if you're still stuck, post what you got so far so that
> > someone can help you.
> >
> > Based on what you've asked, my guess is that CMake isn't what you
> > should be looking into.
> >
> > Ray
> >
> > On Wed, Sep 25, 2019 at 12:22 AM Sachithra Weerasooriya
> > <sachiwee at gmail.com> wrote:
> >>
> >> Hi CMake community!
> >> I am having trouble linking GSL to cmake using command line. I am using a Mac. Can someone please help me?
> >>
> >> Thank you!
> >> Best regards,
> >> Sachi
> >>
> >>
> >> --
> >>
> >> 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 services to support the CMake community. For more information on each offering, please visit:
> >>
> >> CMake Support: http://cmake.org/cmake/help/support.html
> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >> CMake Training Courses: http://cmake.org/cmake/help/training.html
> >>
> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> https://cmake.org/mailman/listinfo/cmake

From avraham.shukron at gmail.com  Tue Sep 24 14:08:06 2019
From: avraham.shukron at gmail.com (Avraham Shukron)
Date: Tue, 24 Sep 2019 21:08:06 +0300
Subject: [CMake] Fwd: Linking GSL to cmake using command line
In-Reply-To: <CAH8UK3UGYzKxiGinNXArmH13oscO-a7WvpGbPmUF9v4_q+F8Cg@mail.gmail.com>
References: <27438CB7-E121-4E39-B17A-8040A385D5D8@gmail.com>
 <CAH8UK3W4bg1Rs-6WJd_6Yv5o4oUodJZAPHd+bPbhicpwppTy8w@mail.gmail.com>
 <EF43F230-CF6B-4AF6-BE93-10717F7BFBA2@gmail.com>
 <CAH8UK3UshEkxFWSh9m+qVm=0_qbtDLHvDTfT4bSz6Oo37xdL0g@mail.gmail.com>
 <CAH8UK3UGYzKxiGinNXArmH13oscO-a7WvpGbPmUF9v4_q+F8Cg@mail.gmail.com>
Message-ID: <CAJX3zAveHGT0xjWmfSOLGR+05owf+H-4sXJOpUWkvK_G20DqJA@mail.gmail.com>

Hi Sachi!

Could you paste a minimal CMakeLists.txt file that demonstrate the problem,
along with details about your OS version and how did you install GSL?

Thanks!

On Tue, Sep 24, 2019 at 7:55 PM Raymond Wan <rwan.work at gmail.com> wrote:

> Hi Sachi and everyone,
>
> Sorry, I didn't realise her original message wasn't CC'ed to the list.
> Please keep replies to the list, Sachi, unless there's a good reason
> you shouldn't.  It will also allow someone to jump in if I've said
> something incorrectly about your problem.
>
> Ray
>
>
> ---------- Forwarded message ---------
> From: Raymond Wan <rwan.work at gmail.com>
> Date: Wed, Sep 25, 2019 at 12:52 AM
> Subject: Re: [CMake] Linking GSL to cmake using command line
> To: Sachithra Weerasooriya <sachiwee at gmail.com>
>
>
> Hi Sachi,
>
> Then, to be frank, it's not something that CMake's users can help you
> with.  It's (most probably) how the developer is using CMake to look
> for GSL and you should be contacting him/her.  Generally, the end user
> of program X shouldn't have to learn about CMake.  (Of course, no one
> is stopping you from learning.)  The developer should be trying to fix
> it, unless you happen to already be an expert on CMake.
>
> If the developer isn't very responsive to your query, then that's a
> separate issue, that's also not related to CMake...  S/he might be
> happy to hear from you since it's a bug report and it can only make
> program X better...I think?
>
> Ray
>
> On Wed, Sep 25, 2019 at 12:38 AM Sachithra Weerasooriya
> <sachiwee at gmail.com> wrote:
> >
> > Hi Ray!
> > Thank you  for your prompt reply! I appreciate it. Actually I am trying
> to install a package that uses cmake. Although GSL is installed in my
> machine, cmake can?t find the GSL directory.
> >
> > Best regards,
> > Sachi
> >
> >
> >
> > Sent from my iPhone
> >
> > > On Sep 24, 2019, at 11:28 AM, Raymond Wan <rwan.work at gmail.com> wrote:
> > >
> > > Hi Sachi,
> > >
> > > Unfortunately, the short answer is "no".  I think you misunderstand
> > > what CMake is.  One way to summarise it is that it allows developers
> > > of programs to describe/explain how to compile and link software.  For
> > > example, suppose there is a program X and it uses the GSL library.  A
> > > programmer might use CMake to explain how GSL can link with X on Mac,
> > > Linux, etc. -- across various platforms.  This will make it easier for
> > > the end user.
> > >
> > > If you are an end user (i.e., you didn't make the program X), then you
> > > need CMake isn't for you.  I'm afraid you might have to read the GSL
> > > documentation for Mac, instead.  If you are the developer of X, then
> > > you might want to go through the various CMake tutorials and give it a
> > > try -- then, if you're still stuck, post what you got so far so that
> > > someone can help you.
> > >
> > > Based on what you've asked, my guess is that CMake isn't what you
> > > should be looking into.
> > >
> > > Ray
> > >
> > > On Wed, Sep 25, 2019 at 12:22 AM Sachithra Weerasooriya
> > > <sachiwee at gmail.com> wrote:
> > >>
> > >> Hi CMake community!
> > >> I am having trouble linking GSL to cmake using command line. I am
> using a Mac. Can someone please help me?
> > >>
> > >> Thank you!
> > >> Best regards,
> > >> Sachi
> > >>
> > >>
> > >> --
> > >>
> > >> 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 services to support the CMake community. For
> more information on each offering, please visit:
> > >>
> > >> CMake Support: http://cmake.org/cmake/help/support.html
> > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > >> CMake Training Courses: http://cmake.org/cmake/help/training.html
> > >>
> > >> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> > >>
> > >> Follow this link to subscribe/unsubscribe:
> > >> https://cmake.org/mailman/listinfo/cmake
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190924/7ce3058b/attachment-0001.html>

From avraham.shukron at gmail.com  Tue Sep 24 16:08:53 2019
From: avraham.shukron at gmail.com (Avraham Shukron)
Date: Tue, 24 Sep 2019 23:08:53 +0300
Subject: [CMake] Fwd: Linking GSL to cmake using command line
In-Reply-To: <CAO9qim+dFOabTuao_ouCPWK3orViEbBgK5w1UU0PCzBBNJ_pPQ@mail.gmail.com>
References: <27438CB7-E121-4E39-B17A-8040A385D5D8@gmail.com>
 <CAH8UK3W4bg1Rs-6WJd_6Yv5o4oUodJZAPHd+bPbhicpwppTy8w@mail.gmail.com>
 <EF43F230-CF6B-4AF6-BE93-10717F7BFBA2@gmail.com>
 <CAH8UK3UshEkxFWSh9m+qVm=0_qbtDLHvDTfT4bSz6Oo37xdL0g@mail.gmail.com>
 <CAH8UK3UGYzKxiGinNXArmH13oscO-a7WvpGbPmUF9v4_q+F8Cg@mail.gmail.com>
 <CAJX3zAveHGT0xjWmfSOLGR+05owf+H-4sXJOpUWkvK_G20DqJA@mail.gmail.com>
 <CAO9qim+dFOabTuao_ouCPWK3orViEbBgK5w1UU0PCzBBNJ_pPQ@mail.gmail.com>
Message-ID: <CAJX3zAuisSuSjzPD83pAb1D22FTZ3yLUqEi_Gi4UsQ37+tyfBg@mail.gmail.com>

The macro looks fine (assuming you actually call it somewhere).
And I also assume that the line that fails is the find_package(GSL REQUIRED)

I suspect that it fails because you installed GSL in a local directory that
is not in a location known to cmake (E.g not in /usr/local/lib or something
similar)

Can you specify the path you installed GSL to?

In order for CMake to find package in a non-standard location, you can set
the GSL_ROOT
<https://cmake.org/cmake/help/latest/variable/PackageName_ROOT.html#packagename-root>
cmake variable before calling find_package(GSL).
You should set it to wherever you installed the GSL library locally.

On Tue, Sep 24, 2019 at 9:37 PM Sachithra Weerasooriya <sachiwee at gmail.com>
wrote:

> Hi Avraham!
> I installed GSL manually using in a local directory. OS version is macOS
> Mojave 10.14.5. Here's part of the file that looks for gsl:
> #
> # How we find GSL and set it up
> #
> macro(find_gsl)
> find_package(GSL REQUIRED)
> list(APPEND VR_INCLUDE_DIRS ${GSL_INCLUDE_DIRS})
> list(APPEND VR_LIBS ${GSL_LIBRARIES})
> endmacro()
>
> #
>
> Thank you!
> Best Regards,
> Sachi
>
> On Tue, Sep 24, 2019 at 1:08 PM Avraham Shukron <avraham.shukron at gmail.com>
> wrote:
>
>> Hi Sachi!
>>
>> Could you paste a minimal CMakeLists.txt file that demonstrate the
>> problem, along with details about your OS version and how did you install
>> GSL?
>>
>> Thanks!
>>
>> On Tue, Sep 24, 2019 at 7:55 PM Raymond Wan <rwan.work at gmail.com> wrote:
>>
>>> Hi Sachi and everyone,
>>>
>>> Sorry, I didn't realise her original message wasn't CC'ed to the list.
>>> Please keep replies to the list, Sachi, unless there's a good reason
>>> you shouldn't.  It will also allow someone to jump in if I've said
>>> something incorrectly about your problem.
>>>
>>> Ray
>>>
>>>
>>> ---------- Forwarded message ---------
>>> From: Raymond Wan <rwan.work at gmail.com>
>>> Date: Wed, Sep 25, 2019 at 12:52 AM
>>> Subject: Re: [CMake] Linking GSL to cmake using command line
>>> To: Sachithra Weerasooriya <sachiwee at gmail.com>
>>>
>>>
>>> Hi Sachi,
>>>
>>> Then, to be frank, it's not something that CMake's users can help you
>>> with.  It's (most probably) how the developer is using CMake to look
>>> for GSL and you should be contacting him/her.  Generally, the end user
>>> of program X shouldn't have to learn about CMake.  (Of course, no one
>>> is stopping you from learning.)  The developer should be trying to fix
>>> it, unless you happen to already be an expert on CMake.
>>>
>>> If the developer isn't very responsive to your query, then that's a
>>> separate issue, that's also not related to CMake...  S/he might be
>>> happy to hear from you since it's a bug report and it can only make
>>> program X better...I think?
>>>
>>> Ray
>>>
>>> On Wed, Sep 25, 2019 at 12:38 AM Sachithra Weerasooriya
>>> <sachiwee at gmail.com> wrote:
>>> >
>>> > Hi Ray!
>>> > Thank you  for your prompt reply! I appreciate it. Actually I am
>>> trying to install a package that uses cmake. Although GSL is installed in
>>> my machine, cmake can?t find the GSL directory.
>>> >
>>> > Best regards,
>>> > Sachi
>>> >
>>> >
>>> >
>>> > Sent from my iPhone
>>> >
>>> > > On Sep 24, 2019, at 11:28 AM, Raymond Wan <rwan.work at gmail.com>
>>> wrote:
>>> > >
>>> > > Hi Sachi,
>>> > >
>>> > > Unfortunately, the short answer is "no".  I think you misunderstand
>>> > > what CMake is.  One way to summarise it is that it allows developers
>>> > > of programs to describe/explain how to compile and link software.
>>> For
>>> > > example, suppose there is a program X and it uses the GSL library.  A
>>> > > programmer might use CMake to explain how GSL can link with X on Mac,
>>> > > Linux, etc. -- across various platforms.  This will make it easier
>>> for
>>> > > the end user.
>>> > >
>>> > > If you are an end user (i.e., you didn't make the program X), then
>>> you
>>> > > need CMake isn't for you.  I'm afraid you might have to read the GSL
>>> > > documentation for Mac, instead.  If you are the developer of X, then
>>> > > you might want to go through the various CMake tutorials and give it
>>> a
>>> > > try -- then, if you're still stuck, post what you got so far so that
>>> > > someone can help you.
>>> > >
>>> > > Based on what you've asked, my guess is that CMake isn't what you
>>> > > should be looking into.
>>> > >
>>> > > Ray
>>> > >
>>> > > On Wed, Sep 25, 2019 at 12:22 AM Sachithra Weerasooriya
>>> > > <sachiwee at gmail.com> wrote:
>>> > >>
>>> > >> Hi CMake community!
>>> > >> I am having trouble linking GSL to cmake using command line. I am
>>> using a Mac. Can someone please help me?
>>> > >>
>>> > >> Thank you!
>>> > >> Best regards,
>>> > >> Sachi
>>> > >>
>>> > >>
>>> > >> --
>>> > >>
>>> > >> 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 services to support the CMake community. For
>>> more information on each offering, please visit:
>>> > >>
>>> > >> CMake Support: http://cmake.org/cmake/help/support.html
>>> > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> > >> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>> > >>
>>> > >> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>> > >>
>>> > >> Follow this link to subscribe/unsubscribe:
>>> > >> https://cmake.org/mailman/listinfo/cmake
>>> --
>>>
>>> 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 services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://cmake.org/mailman/listinfo/cmake
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190924/340ca9b9/attachment.html>

From avraham.shukron at gmail.com  Tue Sep 24 16:41:54 2019
From: avraham.shukron at gmail.com (Avraham Shukron)
Date: Tue, 24 Sep 2019 23:41:54 +0300
Subject: [CMake] Single library with both shared and static binaries
Message-ID: <CAJX3zAu_eU66fPFY9MM00Gc=dDqDEqFuTpoyg+3QeoLx-7c3vw@mail.gmail.com>

Hi!

I have a library which I want to distribute in both shared object and
static library forms.
Is there a modern way to do it without creating two completely
separate library targets?
Since I want to be a good CMake citizen I use `target_*` and
`set_target_properties` as much as possible, and creating two different
libraries will force me to duplicate that information about each one of
them.

I also tries not specifying STATIC/SHARED, and then running cmake twice -
once with BUILD_SHARED_LIBS=ON and once OFF and then installing to the same
directory. I got my both .a and .so libraries installed, but I couldn't get
the Config file correctly for this arrangement.

So - what is the community-recommended pattern to do this?

Thanks,
Avi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190924/40f9f294/attachment.html>

From sachiwee at gmail.com  Tue Sep 24 22:15:27 2019
From: sachiwee at gmail.com (Sachithra Weerasooriya)
Date: Tue, 24 Sep 2019 21:15:27 -0500
Subject: [CMake] Fwd: Linking GSL to cmake using command line
In-Reply-To: <CAJX3zAuisSuSjzPD83pAb1D22FTZ3yLUqEi_Gi4UsQ37+tyfBg@mail.gmail.com>
References: <27438CB7-E121-4E39-B17A-8040A385D5D8@gmail.com>
 <CAH8UK3W4bg1Rs-6WJd_6Yv5o4oUodJZAPHd+bPbhicpwppTy8w@mail.gmail.com>
 <EF43F230-CF6B-4AF6-BE93-10717F7BFBA2@gmail.com>
 <CAH8UK3UshEkxFWSh9m+qVm=0_qbtDLHvDTfT4bSz6Oo37xdL0g@mail.gmail.com>
 <CAH8UK3UGYzKxiGinNXArmH13oscO-a7WvpGbPmUF9v4_q+F8Cg@mail.gmail.com>
 <CAJX3zAveHGT0xjWmfSOLGR+05owf+H-4sXJOpUWkvK_G20DqJA@mail.gmail.com>
 <CAO9qim+dFOabTuao_ouCPWK3orViEbBgK5w1UU0PCzBBNJ_pPQ@mail.gmail.com>
 <CAJX3zAuisSuSjzPD83pAb1D22FTZ3yLUqEi_Gi4UsQ37+tyfBg@mail.gmail.com>
Message-ID: <62F3A16F-7CFA-4E48-AC1A-82F097741953@gmail.com>

 I did install it in a non standard path. Which is why was trying to figure out how to link gsl. I couldn?t use homebrew since I don?t have root permissions on the machine. Do you just edit the text file just before calling find_package statement like this ?
GSL_ROOT_DIR=\path\to\gsl

Thanks!
Best regards,
Sachi



> On Sep 24, 2019, at 3:08 PM, Avraham Shukron <avraham.shukron at gmail.com> wrote:
> 
> The macro looks fine (assuming you actually call it somewhere).
> And I also assume that the line that fails is the find_package(GSL REQUIRED)
> 
> I suspect that it fails because you installed GSL in a local directory that is not in a location known to cmake (E.g not in /usr/local/lib or something similar)
> 
> Can you specify the path you installed GSL to?
> 
> In order for CMake to find package in a non-standard location, you can set the GSL_ROOT cmake variable before calling find_package(GSL).
> You should set it to wherever you installed the GSL library locally.
> 
>> On Tue, Sep 24, 2019 at 9:37 PM Sachithra Weerasooriya <sachiwee at gmail.com> wrote:
>> Hi Avraham!
>> I installed GSL manually using in a local directory. OS version is macOS Mojave 10.14.5. Here's part of the file that looks for gsl:
>> #
>> # How we find GSL and set it up
>> #
>> macro(find_gsl)
>> 	find_package(GSL REQUIRED)
>> 	list(APPEND VR_INCLUDE_DIRS ${GSL_INCLUDE_DIRS})
>> 	list(APPEND VR_LIBS ${GSL_LIBRARIES})
>> endmacro()
>> 
>> #
>> 
>> Thank you!
>> Best Regards,
>> Sachi
>> 
>>> On Tue, Sep 24, 2019 at 1:08 PM Avraham Shukron <avraham.shukron at gmail.com> wrote:
>>> Hi Sachi!
>>> 
>>> Could you paste a minimal CMakeLists.txt file that demonstrate the problem, along with details about your OS version and how did you install GSL?
>>> 
>>> Thanks!
>>> 
>>>> On Tue, Sep 24, 2019 at 7:55 PM Raymond Wan <rwan.work at gmail.com> wrote:
>>>> Hi Sachi and everyone,
>>>> 
>>>> Sorry, I didn't realise her original message wasn't CC'ed to the list.
>>>> Please keep replies to the list, Sachi, unless there's a good reason
>>>> you shouldn't.  It will also allow someone to jump in if I've said
>>>> something incorrectly about your problem.
>>>> 
>>>> Ray
>>>> 
>>>> 
>>>> ---------- Forwarded message ---------
>>>> From: Raymond Wan <rwan.work at gmail.com>
>>>> Date: Wed, Sep 25, 2019 at 12:52 AM
>>>> Subject: Re: [CMake] Linking GSL to cmake using command line
>>>> To: Sachithra Weerasooriya <sachiwee at gmail.com>
>>>> 
>>>> 
>>>> Hi Sachi,
>>>> 
>>>> Then, to be frank, it's not something that CMake's users can help you
>>>> with.  It's (most probably) how the developer is using CMake to look
>>>> for GSL and you should be contacting him/her.  Generally, the end user
>>>> of program X shouldn't have to learn about CMake.  (Of course, no one
>>>> is stopping you from learning.)  The developer should be trying to fix
>>>> it, unless you happen to already be an expert on CMake.
>>>> 
>>>> If the developer isn't very responsive to your query, then that's a
>>>> separate issue, that's also not related to CMake...  S/he might be
>>>> happy to hear from you since it's a bug report and it can only make
>>>> program X better...I think?
>>>> 
>>>> Ray
>>>> 
>>>> On Wed, Sep 25, 2019 at 12:38 AM Sachithra Weerasooriya
>>>> <sachiwee at gmail.com> wrote:
>>>> >
>>>> > Hi Ray!
>>>> > Thank you  for your prompt reply! I appreciate it. Actually I am trying to install a package that uses cmake. Although GSL is installed in my machine, cmake can?t find the GSL directory.
>>>> >
>>>> > Best regards,
>>>> > Sachi
>>>> >
>>>> >
>>>> >
>>>> > Sent from my iPhone
>>>> >
>>>> > > On Sep 24, 2019, at 11:28 AM, Raymond Wan <rwan.work at gmail.com> wrote:
>>>> > >
>>>> > > Hi Sachi,
>>>> > >
>>>> > > Unfortunately, the short answer is "no".  I think you misunderstand
>>>> > > what CMake is.  One way to summarise it is that it allows developers
>>>> > > of programs to describe/explain how to compile and link software.  For
>>>> > > example, suppose there is a program X and it uses the GSL library.  A
>>>> > > programmer might use CMake to explain how GSL can link with X on Mac,
>>>> > > Linux, etc. -- across various platforms.  This will make it easier for
>>>> > > the end user.
>>>> > >
>>>> > > If you are an end user (i.e., you didn't make the program X), then you
>>>> > > need CMake isn't for you.  I'm afraid you might have to read the GSL
>>>> > > documentation for Mac, instead.  If you are the developer of X, then
>>>> > > you might want to go through the various CMake tutorials and give it a
>>>> > > try -- then, if you're still stuck, post what you got so far so that
>>>> > > someone can help you.
>>>> > >
>>>> > > Based on what you've asked, my guess is that CMake isn't what you
>>>> > > should be looking into.
>>>> > >
>>>> > > Ray
>>>> > >
>>>> > > On Wed, Sep 25, 2019 at 12:22 AM Sachithra Weerasooriya
>>>> > > <sachiwee at gmail.com> wrote:
>>>> > >>
>>>> > >> Hi CMake community!
>>>> > >> I am having trouble linking GSL to cmake using command line. I am using a Mac. Can someone please help me?
>>>> > >>
>>>> > >> Thank you!
>>>> > >> Best regards,
>>>> > >> Sachi
>>>> > >>
>>>> > >>
>>>> > >> --
>>>> > >>
>>>> > >> 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 services to support the CMake community. For more information on each offering, please visit:
>>>> > >>
>>>> > >> CMake Support: http://cmake.org/cmake/help/support.html
>>>> > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> > >> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>> > >>
>>>> > >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>> > >>
>>>> > >> Follow this link to subscribe/unsubscribe:
>>>> > >> https://cmake.org/mailman/listinfo/cmake
>>>> -- 
>>>> 
>>>> 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 services to support the CMake community. For more information on each offering, please visit:
>>>> 
>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>> 
>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>> 
>>>> Follow this link to subscribe/unsubscribe:
>>>> https://cmake.org/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190924/41545c78/attachment-0001.html>

From avraham.shukron at gmail.com  Wed Sep 25 01:12:36 2019
From: avraham.shukron at gmail.com (Avraham Shukron)
Date: Wed, 25 Sep 2019 08:12:36 +0300
Subject: [CMake] Fwd: Linking GSL to cmake using command line
In-Reply-To: <62F3A16F-7CFA-4E48-AC1A-82F097741953@gmail.com>
References: <27438CB7-E121-4E39-B17A-8040A385D5D8@gmail.com>
 <CAH8UK3W4bg1Rs-6WJd_6Yv5o4oUodJZAPHd+bPbhicpwppTy8w@mail.gmail.com>
 <EF43F230-CF6B-4AF6-BE93-10717F7BFBA2@gmail.com>
 <CAH8UK3UshEkxFWSh9m+qVm=0_qbtDLHvDTfT4bSz6Oo37xdL0g@mail.gmail.com>
 <CAH8UK3UGYzKxiGinNXArmH13oscO-a7WvpGbPmUF9v4_q+F8Cg@mail.gmail.com>
 <CAJX3zAveHGT0xjWmfSOLGR+05owf+H-4sXJOpUWkvK_G20DqJA@mail.gmail.com>
 <CAO9qim+dFOabTuao_ouCPWK3orViEbBgK5w1UU0PCzBBNJ_pPQ@mail.gmail.com>
 <CAJX3zAuisSuSjzPD83pAb1D22FTZ3yLUqEi_Gi4UsQ37+tyfBg@mail.gmail.com>
 <62F3A16F-7CFA-4E48-AC1A-82F097741953@gmail.com>
Message-ID: <CAJX3zAs0E9xJ2+ka0MRnJZCnu9KebLCADzoAoAOquq_-kFF3AQ@mail.gmail.com>

No, setting a variable in cmake is done with the 'set(GSL_ROOT
/path/to/gsl)' command.

You can alternatively set a similarly named environment variable when
invoking cmake:

GSL_ROOT="/path/to/gsl" cmake <path to source dir>


On Wed, Sep 25, 2019, 05:15 Sachithra Weerasooriya <sachiwee at gmail.com>
wrote:

>  I did install it in a non standard path. Which is why was trying to
> figure out how to link gsl. I couldn?t use homebrew since I don?t have root
> permissions on the machine. Do you just edit the text file just before
> calling find_package statement like this ?
> GSL_ROOT_DIR=\path\to\gsl
>
> Thanks!
> Best regards,
> Sachi
>
>
>
> On Sep 24, 2019, at 3:08 PM, Avraham Shukron <avraham.shukron at gmail.com>
> wrote:
>
> The macro looks fine (assuming you actually call it somewhere).
> And I also assume that the line that fails is the find_package(GSL
> REQUIRED)
>
> I suspect that it fails because you installed GSL in a local directory
> that is not in a location known to cmake (E.g not in /usr/local/lib or
> something similar)
>
> Can you specify the path you installed GSL to?
>
> In order for CMake to find package in a non-standard location, you can set
> the GSL_ROOT
> <https://cmake.org/cmake/help/latest/variable/PackageName_ROOT.html#packagename-root>
> cmake variable before calling find_package(GSL).
> You should set it to wherever you installed the GSL library locally.
>
> On Tue, Sep 24, 2019 at 9:37 PM Sachithra Weerasooriya <sachiwee at gmail.com>
> wrote:
>
>> Hi Avraham!
>> I installed GSL manually using in a local directory. OS version is macOS
>> Mojave 10.14.5. Here's part of the file that looks for gsl:
>> #
>> # How we find GSL and set it up
>> #
>> macro(find_gsl)
>> find_package(GSL REQUIRED)
>> list(APPEND VR_INCLUDE_DIRS ${GSL_INCLUDE_DIRS})
>> list(APPEND VR_LIBS ${GSL_LIBRARIES})
>> endmacro()
>>
>> #
>>
>> Thank you!
>> Best Regards,
>> Sachi
>>
>> On Tue, Sep 24, 2019 at 1:08 PM Avraham Shukron <
>> avraham.shukron at gmail.com> wrote:
>>
>>> Hi Sachi!
>>>
>>> Could you paste a minimal CMakeLists.txt file that demonstrate the
>>> problem, along with details about your OS version and how did you install
>>> GSL?
>>>
>>> Thanks!
>>>
>>> On Tue, Sep 24, 2019 at 7:55 PM Raymond Wan <rwan.work at gmail.com> wrote:
>>>
>>>> Hi Sachi and everyone,
>>>>
>>>> Sorry, I didn't realise her original message wasn't CC'ed to the list.
>>>> Please keep replies to the list, Sachi, unless there's a good reason
>>>> you shouldn't.  It will also allow someone to jump in if I've said
>>>> something incorrectly about your problem.
>>>>
>>>> Ray
>>>>
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: Raymond Wan <rwan.work at gmail.com>
>>>> Date: Wed, Sep 25, 2019 at 12:52 AM
>>>> Subject: Re: [CMake] Linking GSL to cmake using command line
>>>> To: Sachithra Weerasooriya <sachiwee at gmail.com>
>>>>
>>>>
>>>> Hi Sachi,
>>>>
>>>> Then, to be frank, it's not something that CMake's users can help you
>>>> with.  It's (most probably) how the developer is using CMake to look
>>>> for GSL and you should be contacting him/her.  Generally, the end user
>>>> of program X shouldn't have to learn about CMake.  (Of course, no one
>>>> is stopping you from learning.)  The developer should be trying to fix
>>>> it, unless you happen to already be an expert on CMake.
>>>>
>>>> If the developer isn't very responsive to your query, then that's a
>>>> separate issue, that's also not related to CMake...  S/he might be
>>>> happy to hear from you since it's a bug report and it can only make
>>>> program X better...I think?
>>>>
>>>> Ray
>>>>
>>>> On Wed, Sep 25, 2019 at 12:38 AM Sachithra Weerasooriya
>>>> <sachiwee at gmail.com> wrote:
>>>> >
>>>> > Hi Ray!
>>>> > Thank you  for your prompt reply! I appreciate it. Actually I am
>>>> trying to install a package that uses cmake. Although GSL is installed in
>>>> my machine, cmake can?t find the GSL directory.
>>>> >
>>>> > Best regards,
>>>> > Sachi
>>>> >
>>>> >
>>>> >
>>>> > Sent from my iPhone
>>>> >
>>>> > > On Sep 24, 2019, at 11:28 AM, Raymond Wan <rwan.work at gmail.com>
>>>> wrote:
>>>> > >
>>>> > > Hi Sachi,
>>>> > >
>>>> > > Unfortunately, the short answer is "no".  I think you misunderstand
>>>> > > what CMake is.  One way to summarise it is that it allows developers
>>>> > > of programs to describe/explain how to compile and link software.
>>>> For
>>>> > > example, suppose there is a program X and it uses the GSL library.
>>>> A
>>>> > > programmer might use CMake to explain how GSL can link with X on
>>>> Mac,
>>>> > > Linux, etc. -- across various platforms.  This will make it easier
>>>> for
>>>> > > the end user.
>>>> > >
>>>> > > If you are an end user (i.e., you didn't make the program X), then
>>>> you
>>>> > > need CMake isn't for you.  I'm afraid you might have to read the GSL
>>>> > > documentation for Mac, instead.  If you are the developer of X, then
>>>> > > you might want to go through the various CMake tutorials and give
>>>> it a
>>>> > > try -- then, if you're still stuck, post what you got so far so that
>>>> > > someone can help you.
>>>> > >
>>>> > > Based on what you've asked, my guess is that CMake isn't what you
>>>> > > should be looking into.
>>>> > >
>>>> > > Ray
>>>> > >
>>>> > > On Wed, Sep 25, 2019 at 12:22 AM Sachithra Weerasooriya
>>>> > > <sachiwee at gmail.com> wrote:
>>>> > >>
>>>> > >> Hi CMake community!
>>>> > >> I am having trouble linking GSL to cmake using command line. I am
>>>> using a Mac. Can someone please help me?
>>>> > >>
>>>> > >> Thank you!
>>>> > >> Best regards,
>>>> > >> Sachi
>>>> > >>
>>>> > >>
>>>> > >> --
>>>> > >>
>>>> > >> 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 services to support the CMake community.
>>>> For more information on each offering, please visit:
>>>> > >>
>>>> > >> CMake Support: http://cmake.org/cmake/help/support.html
>>>> > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> > >> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>> > >>
>>>> > >> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>> > >>
>>>> > >> Follow this link to subscribe/unsubscribe:
>>>> > >> https://cmake.org/mailman/listinfo/cmake
>>>> --
>>>>
>>>> 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 services to support the CMake community. For
>>>> more information on each offering, please visit:
>>>>
>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> https://cmake.org/mailman/listinfo/cmake
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190925/6e02d444/attachment.html>

From doenges at mvtec.com  Wed Sep 25 03:50:06 2019
From: doenges at mvtec.com (Eric Doenges)
Date: Wed, 25 Sep 2019 09:50:06 +0200
Subject: [CMake] MacOS and shared libraries from imported targets
In-Reply-To: <y2tdef8sqdfzt3.fsf@lx-birch.ad.sei.cmu.edu>
References: <y2tdef8sqdfzt3.fsf@lx-birch.ad.sei.cmu.edu>
Message-ID: <0f29b6ee-94a1-dade-ce37-7877b3f018e3@mvtec.com>

As far as I am aware, the macOS linker simply records the install name 
of the dynamic library you link against in your executable (similar to 
how the Linux linker records the Elf SONAME, if present). So, the first 
step would be to check the install name of the external dynamic library 
by running 'otool -L' on it (the install name should be at the top of 
the output). You can change the install name using the install_name_tool 
(but if you build the external dynamic library yourself I think it is 
better to build the library with the correct install name in the first 
place).

Am 24.09.19 um 18:02 schrieb Michael Welsh Duggan:
> I have a project that links against an external dynamic library for
> which I have written a Find module that creates an import target.  I do
> this, in part, by setting the IMPORTED_LOCATION property of the target
> to the location of the dynamic library.
>
> Unfortunately, on OSX the library shows up in the executable load
> commands as an LC_LOAD_DYLIB of the raw filename (no directory) of the
> shared library.  I expected it to use the whole path.  I tried setting
> the INSTALL_NAME_DIR property to the directory containing the shared
> library, but this changed nothing.
>
> I will note that this is all still in the build location, as opposed to
> post-install.  I am using the following settings currently:
>
> set(CMAKE_SKIP_BUILD_RPATH false)
> set(CMAKE_BUILD_WITH_INSTALL_RPATH false)
> set(CMAKE_INSTALL_RPATH_USE_LINK_PATH true)
> set(CMAKE_MACOSX_RPATH true)
>
> I'm not 100% confident with how these options interact, so I am more
> than prepared for someone to tell me that I am doing something wrong.
> Any hints would be appreciated.
>
-- 

*Dr. Eric D?nges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doenges at mvtec.com <mailto:mustermann at mvtec.com> | Tel: +49 89 457 695-0 
| www.mvtec.com <http://www.mvtec.com>

Find our privacy policy here <https://www.mvtec.com/imprint>.

Sign up <https://www.mvtec.com/newsletter> for our MVTec Newsletter!

Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht M?nchen HRB 114695

MVTec Software GmbH Logo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190925/c6e08942/attachment-0001.html>

From kyle.edwards at kitware.com  Wed Sep 25 09:43:44 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Wed, 25 Sep 2019 09:43:44 -0400
Subject: [CMake] Single library with both shared and static binaries
In-Reply-To: <CAJX3zAu_eU66fPFY9MM00Gc=dDqDEqFuTpoyg+3QeoLx-7c3vw@mail.gmail.com>
References: <CAJX3zAu_eU66fPFY9MM00Gc=dDqDEqFuTpoyg+3QeoLx-7c3vw@mail.gmail.com>
Message-ID: <1569419024.21309.4.camel@kitware.com>

On Tue, 2019-09-24 at 23:41 +0300, Avraham Shukron wrote:
> Hi!
> 
> I have a library which I want to distribute in both shared object and
> static library forms.
> Is there a modern way to do it without creating two completely
> separate?library targets?
> Since I want to be a good CMake citizen I use `target_*` and
> `set_target_properties` as much?as possible, and creating two
> different libraries will force me to duplicate that information about
> each one of them.
> 
> I also tries not specifying STATIC/SHARED, and then running cmake
> twice - once with BUILD_SHARED_LIBS=ON and once OFF and then
> installing to the same directory. I got my both .a and .so libraries
> installed, but I couldn't get the Config file correctly for this
> arrangement.
> 
> So - what is the community-recommended pattern to do this?

Unfortunately, the recommendation is to do exactly what you don't want
to do: create a shared target and a static target.

To make this slightly simpler, you can use functions to de-duplicate
the target_* and set_target_properties calls:

function(create_foo_target name type)
? add_library(${name} ${type} foo.c foo.h)
? set_target_properties(${name} OUTPUT_NAME foo)
endfunction()

create_foo_target(foo_shared SHARED)
create_foo_target(foo_static STATIC)

Kyle

From Simon.Richter at hogyros.de  Thu Sep 26 08:28:56 2019
From: Simon.Richter at hogyros.de (Simon Richter)
Date: Thu, 26 Sep 2019 14:28:56 +0200
Subject: [CMake] Single library with both shared and static binaries
In-Reply-To: <CAJX3zAu_eU66fPFY9MM00Gc=dDqDEqFuTpoyg+3QeoLx-7c3vw@mail.gmail.com>
References: <CAJX3zAu_eU66fPFY9MM00Gc=dDqDEqFuTpoyg+3QeoLx-7c3vw@mail.gmail.com>
Message-ID: <20190926122856.GA7041@psi5.com>

Hi,

On Tue, Sep 24, 2019 at 11:41:54PM +0300, Avraham Shukron wrote:

> I have a library which I want to distribute in both shared object and
> static library forms.

Is that a requirement for your project, or a requirement for the system
integrator?

With my Debian Developer hat on, I'm always grateful when a project's build
system doesn't do anything unexpected.

We know that libtool generates shared and static libraries at the same
time, and so when wrapping an autoconf based project, we use a single build
tree and expect both to pop up.

With CMake, we know that the build system cannot generate both at the same
time. It would be cool if it could, but the expectation is that a library
project will have to be built twice, and our tools mirror that expectation.

If the majority of your users compile from source and need both shared and
static libraries to be built, it makes sense to have two targets.
Otherwise, the principle of least surprise applies.

That said, a hypothetical future version of CMake that makes this easier so
we can at some point remove the requirement to build twice would be
awesome.

   Simon

From juan.e.sanchez at gmail.com  Thu Sep 26 10:37:45 2019
From: juan.e.sanchez at gmail.com (Juan Sanchez)
Date: Thu, 26 Sep 2019 09:37:45 -0500
Subject: [CMake] Single library with both shared and static binaries
In-Reply-To: <1569419024.21309.4.camel@kitware.com>
References: <CAJX3zAu_eU66fPFY9MM00Gc=dDqDEqFuTpoyg+3QeoLx-7c3vw@mail.gmail.com>
 <1569419024.21309.4.camel@kitware.com>
Message-ID: <CAEHOsR2aR79emDbVN7V25=VgqAK4VP7tjw+wyHDBoqjR7i5_Wg@mail.gmail.com>

Here is an example where two libraries are created from object files that
have only been compiled once:

ADD_LIBRARY(symdiff_objects OBJECT ${CXX_SRCS} ${MC_SRCS})
set_property(TARGET symdiff_objects PROPERTY POSITION_INDEPENDENT_CODE ON)
ADD_LIBRARY(symdiff_dynamic STATIC $<TARGET_OBJECTS:symdiff_objects>)
ADD_LIBRARY(symdiff SHARED $<TARGET_OBJECTS:symdiff_objects>)

The "symdiff_dynamic" library is a static archive that can then be linked
into another shared library or an executable. The "symdiff" library is a
standalone object.  The POSITION_INDEPENDENT_CODE property is required for
the linux platform, but not for macOS or Windows.  If the original poster
is comfortable with having a PIC static library, this is an approach they
can take.

Regards,

Juan

On Wed, Sep 25, 2019 at 8:43 AM Kyle Edwards via CMake <cmake at cmake.org>
wrote:

> On Tue, 2019-09-24 at 23:41 +0300, Avraham Shukron wrote:
> > Hi!
> >
> > I have a library which I want to distribute in both shared object and
> > static library forms.
> > Is there a modern way to do it without creating two completely
> > separate library targets?
> > Since I want to be a good CMake citizen I use `target_*` and
> > `set_target_properties` as much as possible, and creating two
> > different libraries will force me to duplicate that information about
> > each one of them.
> >
> > I also tries not specifying STATIC/SHARED, and then running cmake
> > twice - once with BUILD_SHARED_LIBS=ON and once OFF and then
> > installing to the same directory. I got my both .a and .so libraries
> > installed, but I couldn't get the Config file correctly for this
> > arrangement.
> >
> > So - what is the community-recommended pattern to do this?
>
> Unfortunately, the recommendation is to do exactly what you don't want
> to do: create a shared target and a static target.
>
> To make this slightly simpler, you can use functions to de-duplicate
> the target_* and set_target_properties calls:
>
> function(create_foo_target name type)
>   add_library(${name} ${type} foo.c foo.h)
>   set_target_properties(${name} OUTPUT_NAME foo)
> endfunction()
>
> create_foo_target(foo_shared SHARED)
> create_foo_target(foo_static STATIC)
>
> Kyle
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190926/0aff72f6/attachment.html>

From enrike.gonzalez.98 at gmail.com  Thu Sep 26 11:28:45 2019
From: enrike.gonzalez.98 at gmail.com (=?UTF-8?Q?Enrique_Gonz=C3=A1lez?=)
Date: Thu, 26 Sep 2019 17:28:45 +0200
Subject: [CMake] Cmake error
Message-ID: <CAGuGZp7mfRiZn1Xi1U41SdYApjeQoY=xKJNnL0L0W-EJrWjtuQ@mail.gmail.com>

Dear all,

I'm trying to install LLVM with all the projects because I need Clang and
the SPIR-V target. I am using cmake like the llvm manual says and it give
me this error, could you help me to solve it?

I am following the steps from this page:
https://llvm.org/docs/GettingStarted.html

CMAKE ERROR TRACE:

enrique at enrique-VirtualBox:~/Escritorio/llvm-project/build$ cmake
-DLLVM_ENABLE_PROJECTS='all' -DCMAKE_BUILD_TYPE=Release -G 'Ninja' ../llvm
-- clang project is enabled
-- clang-tools-extra project is enabled
-- compiler-rt project is enabled
-- debuginfo-tests project is enabled
-- libclc project is enabled
-- libcxx project is enabled
-- libcxxabi project is enabled
-- libunwind project is enabled
-- lld project is enabled
-- lldb project is enabled
-- llgo project is enabled
-- openmp project is enabled
-- parallel-libs project is enabled
-- polly project is enabled
-- pstl project is enabled
-- Could NOT find Z3: Found unsuitable version "0.0.0", but required is at
least "4.7.1" (found Z3_LIBRARIES-NOTFOUND)
-- Could NOT find LibXml2 (missing: LIBXML2_LIBRARY LIBXML2_INCLUDE_DIR)
-- Native target architecture is X86
-- Threads enabled.
-- Doxygen disabled.
-- Go bindings disabled.
-- Ninja version: 1.8.2
-- Could NOT find OCaml (missing: OCAMLFIND OCAML_VERSION OCAML_STDLIB_PATH)
-- Could NOT find OCaml (missing: OCAMLFIND OCAML_VERSION OCAML_STDLIB_PATH)
-- OCaml bindings disabled.
-- LLVM host triple: x86_64-unknown-linux-gnu
-- LLVM default target triple: x86_64-unknown-linux-gnu
-- Building with -fPIC
-- Constructing LLVMBuild project information
-- Linker detection: GNU ld
-- Targeting AArch64
-- Targeting AMDGPU
-- Targeting ARM
-- Targeting BPF
-- Targeting Hexagon
-- Targeting Lanai
-- Targeting Mips
-- Targeting MSP430
-- Targeting NVPTX
-- Targeting PowerPC
-- Targeting RISCV
-- Targeting Sparc
-- Targeting SystemZ
-- Targeting WebAssembly
-- Targeting X86
-- Targeting XCore
-- Failed to locate sphinx-build executable (missing: SPHINX_EXECUTABLE)
-- Linker detection: GNU ld
-- Parallel STL uses the serial backend
-- Linker detection: GNU ld
-- Linker detection: GNU ld
-- gdb found: /usr/bin/gdb
-- Linker detection: GNU ld
-- Compiler-RT supported architectures: x86_64
-- Builtin supported architectures: x86_64
-- Linker detection: GNU ld
-- Linker detection: GNU ld
-- Builtin supported architectures: x86_64
-- Generated Sanitizer SUPPORTED_TOOLS list on "Linux" is
"asan;lsan;msan;tsan;ubsan"
-- sanitizer_common tests on "Linux" will run against
"asan;lsan;msan;tsan;ubsan"
-- check-shadowcallstack does nothing.
-- Could NOT find LIBOMPTARGET_DEP_LIBELF (missing:
LIBOMPTARGET_DEP_LIBELF_LIBRARIES LIBOMPTARGET_DEP_LIBELF_INCLUDE_DIRS)
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
-- Could NOT find LIBOMPTARGET_DEP_CUDA_DRIVER (missing:
LIBOMPTARGET_DEP_CUDA_DRIVER_LIBRARIES)
-- LIBOMPTARGET: Building offloading runtime library libomptarget.
-- LIBOMPTARGET: Not building aarch64 offloading plugin: machine not found
in the system.
-- LIBOMPTARGET: Not building CUDA offloading plugin: libelf dependency not
found.
-- LIBOMPTARGET: Not building PPC64 offloading plugin: machine not found in
the system.
-- LIBOMPTARGET: Not building PPC64le offloading plugin: machine not found
in the system.
-- LIBOMPTARGET: Not building x86_64 offloading plugin: libelf dependency
not found.
-- LIBOMPTARGET: Not building CUDA offloading device RTL: CUDA tools not
found in the system.
-- ISL version: isl-0.20-65-gb822a210
-- PPCG version: ppcg-0.07
-- Clang version: 10.0.0
CMake Error at /usr/share/cmake-3.10/Modules/ExternalProject.cmake:2759
(get_property):
  get_property could not find TARGET llgo.  Perhaps it has not yet been
  created.
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/ExternalProject.cmake:3032
(_ep_add_configure_command)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:200
(externalproject_add)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:219
(add_libgo_variant)


CMake Error at /usr/share/cmake-3.10/Modules/ExternalProject.cmake:2759
(get_property):
  get_property could not find TARGET cc-wrapper.  Perhaps it has not yet
been
  created.
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/ExternalProject.cmake:3032
(_ep_add_configure_command)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:200
(externalproject_add)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:219
(add_libgo_variant)


CMake Error at /usr/share/cmake-3.10/Modules/ExternalProject.cmake:2759
(get_property):
  get_property could not find TARGET llgo.  Perhaps it has not yet been
  created.
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/ExternalProject.cmake:3032
(_ep_add_configure_command)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:200
(externalproject_add)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:222
(add_libgo_variant)


CMake Error at /usr/share/cmake-3.10/Modules/ExternalProject.cmake:2759
(get_property):
  get_property could not find TARGET cc-wrapper.  Perhaps it has not yet
been
  created.
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/ExternalProject.cmake:3032
(_ep_add_configure_command)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:200
(externalproject_add)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:222
(add_libgo_variant)


CMake Error at /usr/share/cmake-3.10/Modules/ExternalProject.cmake:2759
(get_property):
  get_property could not find TARGET llgo.  Perhaps it has not yet been
  created.
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/ExternalProject.cmake:3032
(_ep_add_configure_command)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:200
(externalproject_add)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:226
(add_libgo_variant)


CMake Error at /usr/share/cmake-3.10/Modules/ExternalProject.cmake:2759
(get_property):
  get_property could not find TARGET cc-wrapper.  Perhaps it has not yet
been
  created.
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/ExternalProject.cmake:3032
(_ep_add_configure_command)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:200
(externalproject_add)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:226
(add_libgo_variant)


CMake Error at /usr/share/cmake-3.10/Modules/ExternalProject.cmake:2759
(get_property):
  get_property could not find TARGET llgo.  Perhaps it has not yet been
  created.
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/ExternalProject.cmake:3032
(_ep_add_configure_command)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:200
(externalproject_add)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:230
(add_libgo_variant)


CMake Error at /usr/share/cmake-3.10/Modules/ExternalProject.cmake:2759
(get_property):
  get_property could not find TARGET cc-wrapper.  Perhaps it has not yet
been
  created.
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/ExternalProject.cmake:3032
(_ep_add_configure_command)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:200
(externalproject_add)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:230
(add_libgo_variant)


CMake Error at /usr/share/cmake-3.10/Modules/ExternalProject.cmake:2759
(get_property):
  get_property could not find TARGET llgo.  Perhaps it has not yet been
  created.
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/ExternalProject.cmake:3032
(_ep_add_configure_command)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:200
(externalproject_add)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:234
(add_libgo_variant)


CMake Error at /usr/share/cmake-3.10/Modules/ExternalProject.cmake:2759
(get_property):
  get_property could not find TARGET cc-wrapper.  Perhaps it has not yet
been
  created.
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/ExternalProject.cmake:3032
(_ep_add_configure_command)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:200
(externalproject_add)
  /home/enrique/Escritorio/llvm-project/llgo/CMakeLists.txt:234
(add_libgo_variant)


-- LLD version: 10.0.0
CMake Error at
/usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:137
(message):
  Could NOT find LibEdit (missing: libedit_INCLUDE_DIRS libedit_LIBRARIES)
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:378
(_FPHSA_FAILURE_MESSAGE)

/home/enrique/Escritorio/llvm-project/lldb/cmake/modules/FindLibEdit.cmake:54
(find_package_handle_standard_args)

/home/enrique/Escritorio/llvm-project/lldb/cmake/modules/LLDBConfig.cmake:104
(find_package)
  /home/enrique/Escritorio/llvm-project/lldb/CMakeLists.txt:21 (include)


-- Configuring incomplete, errors occurred!
See also
"/home/enrique/Escritorio/llvm-project/build/CMakeFiles/CMakeOutput.log".
See also
"/home/enrique/Escritorio/llvm-project/build/CMakeFiles/CMakeError.log".

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190926/a09269be/attachment-0001.html>

From avraham.shukron at gmail.com  Thu Sep 26 16:06:25 2019
From: avraham.shukron at gmail.com (Avraham Shukron)
Date: Thu, 26 Sep 2019 23:06:25 +0300
Subject: [CMake] Single library with both shared and static binaries
In-Reply-To: <CAEHOsR2aR79emDbVN7V25=VgqAK4VP7tjw+wyHDBoqjR7i5_Wg@mail.gmail.com>
References: <CAJX3zAu_eU66fPFY9MM00Gc=dDqDEqFuTpoyg+3QeoLx-7c3vw@mail.gmail.com>
 <1569419024.21309.4.camel@kitware.com>
 <CAEHOsR2aR79emDbVN7V25=VgqAK4VP7tjw+wyHDBoqjR7i5_Wg@mail.gmail.com>
Message-ID: <CAJX3zAs50pcM+Pak_n9c=Rs9ah7PhzHaUk1mSsg_FJaLA0TOeA@mail.gmail.com>

There is no hard requirement for shipping both static and shared. With the
back against the wall I could get away with SHARED only, since it is the
most common way the library will be consumed. I wanted to also distribute a
static version just for those who want a single, self-contained executable.

I understand that static and shared libraries ARE in fact two different
target, but for the most part they are configured the same way and have the
same properties.

The fact that the recommended practice is to NOT specify SHARED / STATIC in
add_library and let the user decide which one to compile using
BUILD_SHARED_LIBS, proves that a library target is expected to be
independent on whether it is compiled as a shared object or static library.

I agree that it would be great to have the ability to produce both shared
and static binaries from a single library target, although we need to think
of how users importing such target, will be able to specify if they want to
link against the static or the shared binary.


On Thu, Sep 26, 2019 at 5:38 PM Juan Sanchez <juan.e.sanchez at gmail.com>
wrote:

> Here is an example where two libraries are created from object files that
> have only been compiled once:
>
> ADD_LIBRARY(symdiff_objects OBJECT ${CXX_SRCS} ${MC_SRCS})
> set_property(TARGET symdiff_objects PROPERTY POSITION_INDEPENDENT_CODE ON)
> ADD_LIBRARY(symdiff_dynamic STATIC $<TARGET_OBJECTS:symdiff_objects>)
> ADD_LIBRARY(symdiff SHARED $<TARGET_OBJECTS:symdiff_objects>)
>
> The "symdiff_dynamic" library is a static archive that can then be linked
> into another shared library or an executable. The "symdiff" library is a
> standalone object.  The POSITION_INDEPENDENT_CODE property is required for
> the linux platform, but not for macOS or Windows.  If the original poster
> is comfortable with having a PIC static library, this is an approach they
> can take.
>
> Regards,
>
> Juan
>
> On Wed, Sep 25, 2019 at 8:43 AM Kyle Edwards via CMake <cmake at cmake.org>
> wrote:
>
>> On Tue, 2019-09-24 at 23:41 +0300, Avraham Shukron wrote:
>> > Hi!
>> >
>> > I have a library which I want to distribute in both shared object and
>> > static library forms.
>> > Is there a modern way to do it without creating two completely
>> > separate library targets?
>> > Since I want to be a good CMake citizen I use `target_*` and
>> > `set_target_properties` as much as possible, and creating two
>> > different libraries will force me to duplicate that information about
>> > each one of them.
>> >
>> > I also tries not specifying STATIC/SHARED, and then running cmake
>> > twice - once with BUILD_SHARED_LIBS=ON and once OFF and then
>> > installing to the same directory. I got my both .a and .so libraries
>> > installed, but I couldn't get the Config file correctly for this
>> > arrangement.
>> >
>> > So - what is the community-recommended pattern to do this?
>>
>> Unfortunately, the recommendation is to do exactly what you don't want
>> to do: create a shared target and a static target.
>>
>> To make this slightly simpler, you can use functions to de-duplicate
>> the target_* and set_target_properties calls:
>>
>> function(create_foo_target name type)
>>   add_library(${name} ${type} foo.c foo.h)
>>   set_target_properties(${name} OUTPUT_NAME foo)
>> endfunction()
>>
>> create_foo_target(foo_shared SHARED)
>> create_foo_target(foo_static STATIC)
>>
>> Kyle
>> --
>>
>> 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 services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190926/c72d3dc2/attachment.html>

From d3ck0r at gmail.com  Thu Sep 26 22:02:21 2019
From: d3ck0r at gmail.com (J Decker)
Date: Thu, 26 Sep 2019 19:02:21 -0700
Subject: [CMake] Single library with both shared and static binaries
In-Reply-To: <CAJX3zAs50pcM+Pak_n9c=Rs9ah7PhzHaUk1mSsg_FJaLA0TOeA@mail.gmail.com>
References: <CAJX3zAu_eU66fPFY9MM00Gc=dDqDEqFuTpoyg+3QeoLx-7c3vw@mail.gmail.com>
 <1569419024.21309.4.camel@kitware.com>
 <CAEHOsR2aR79emDbVN7V25=VgqAK4VP7tjw+wyHDBoqjR7i5_Wg@mail.gmail.com>
 <CAJX3zAs50pcM+Pak_n9c=Rs9ah7PhzHaUk1mSsg_FJaLA0TOeA@mail.gmail.com>
Message-ID: <CAA2GJqWck3Nr13bZSv7RonCbT6Fij_jZxCNvTgG20PUwS0OA6w@mail.gmail.com>

I ended up using external_project() because unless you also copy the source
files, each source file each only gets one set of flags... so if you have
different compile options (the config file I suppose) the sources will only
build with one or the other.

If you copy all of the sources to the CMAKE_BiNARY_DIR (which can be done
passing a list of sources to a macro, which can then extract the path part
and append it) then use copy_file_if_different()  (And I additionally touch
that file to make sure the copy definitely gets built when it dos get
copied)  then you can build two targets with different options for the
sources.

Otherwise, an internal external project works pretty well.
https://github.com/d3x0r/SACK/blob/master/binary/CMakeLists.txt#L61

I kinda moved away from building both dynamic static libaries,and the
static binaries are just external projects that reference the original
sources.


On Thu, Sep 26, 2019 at 1:06 PM Avraham Shukron <avraham.shukron at gmail.com>
wrote:

> There is no hard requirement for shipping both static and shared. With the
> back against the wall I could get away with SHARED only, since it is the
> most common way the library will be consumed. I wanted to also distribute a
> static version just for those who want a single, self-contained executable.
>
> I understand that static and shared libraries ARE in fact two different
> target, but for the most part they are configured the same way and have the
> same properties.
>
> The fact that the recommended practice is to NOT specify SHARED / STATIC
> in add_library and let the user decide which one to compile using
> BUILD_SHARED_LIBS, proves that a library target is expected to be
> independent on whether it is compiled as a shared object or static library.
>
> I agree that it would be great to have the ability to produce both shared
> and static binaries from a single library target, although we need to think
> of how users importing such target, will be able to specify if they want to
> link against the static or the shared binary.
>
>
> On Thu, Sep 26, 2019 at 5:38 PM Juan Sanchez <juan.e.sanchez at gmail.com>
> wrote:
>
>> Here is an example where two libraries are created from object files that
>> have only been compiled once:
>>
>> ADD_LIBRARY(symdiff_objects OBJECT ${CXX_SRCS} ${MC_SRCS})
>> set_property(TARGET symdiff_objects PROPERTY POSITION_INDEPENDENT_CODE ON)
>> ADD_LIBRARY(symdiff_dynamic STATIC $<TARGET_OBJECTS:symdiff_objects>)
>> ADD_LIBRARY(symdiff SHARED $<TARGET_OBJECTS:symdiff_objects>)
>>
>> The "symdiff_dynamic" library is a static archive that can then be linked
>> into another shared library or an executable. The "symdiff" library is a
>> standalone object.  The POSITION_INDEPENDENT_CODE property is required for
>> the linux platform, but not for macOS or Windows.  If the original poster
>> is comfortable with having a PIC static library, this is an approach they
>> can take.
>>
>> Regards,
>>
>> Juan
>>
>> On Wed, Sep 25, 2019 at 8:43 AM Kyle Edwards via CMake <cmake at cmake.org>
>> wrote:
>>
>>> On Tue, 2019-09-24 at 23:41 +0300, Avraham Shukron wrote:
>>> > Hi!
>>> >
>>> > I have a library which I want to distribute in both shared object and
>>> > static library forms.
>>> > Is there a modern way to do it without creating two completely
>>> > separate library targets?
>>> > Since I want to be a good CMake citizen I use `target_*` and
>>> > `set_target_properties` as much as possible, and creating two
>>> > different libraries will force me to duplicate that information about
>>> > each one of them.
>>> >
>>> > I also tries not specifying STATIC/SHARED, and then running cmake
>>> > twice - once with BUILD_SHARED_LIBS=ON and once OFF and then
>>> > installing to the same directory. I got my both .a and .so libraries
>>> > installed, but I couldn't get the Config file correctly for this
>>> > arrangement.
>>> >
>>> > So - what is the community-recommended pattern to do this?
>>>
>>> Unfortunately, the recommendation is to do exactly what you don't want
>>> to do: create a shared target and a static target.
>>>
>>> To make this slightly simpler, you can use functions to de-duplicate
>>> the target_* and set_target_properties calls:
>>>
>>> function(create_foo_target name type)
>>>   add_library(${name} ${type} foo.c foo.h)
>>>   set_target_properties(${name} OUTPUT_NAME foo)
>>> endfunction()
>>>
>>> create_foo_target(foo_shared SHARED)
>>> create_foo_target(foo_static STATIC)
>>>
>>> Kyle
>>> --
>>>
>>> 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 services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://cmake.org/mailman/listinfo/cmake
>>>
>> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190926/7d5093a1/attachment-0001.html>

From marek.vojtko at oxidegames.com  Fri Sep 27 12:00:02 2019
From: marek.vojtko at oxidegames.com (Marek Vojtko)
Date: Fri, 27 Sep 2019 16:00:02 +0000
Subject: [CMake] Project Structure and add_subdirectory()
Message-ID: <CY4PR19MB0102976638002A9F4E14076EEA810@CY4PR19MB0102.namprd19.prod.outlook.com>

Using add_subdirectory() in a "superbuild" setup is straightforward: Create a root CMakeLists.txt which calls add_subdirectory() on all directories of your project and each target can then use target_link_libraries() without worrying where the target came from.

Unfortunately the "superbuild" setup also means that each target is compiled exactly once, which means that you cannot change a target's build environment per-application (e.g. preprocessor definitions that change the sizes of stack arrays).

If I need per-application control of its dependencies' build environment I can have each application's CMakeLists.txt call add_subdirectory() for all of its dependencies. However, that means that each application now has to know all of its *transitive* dependencies and the application's CMakeLists.txt has to be kept up-to-date with any changes in its dependency tree, no matter how deep. So if AppA depends on LibA, which depends on LibB, which depends on LibC. Not only does AppA's CMakeLists.txt have to call add_subdirectory() on LibA, LibB, and LibC, but if LibC is modified to depend on LibX, now AppA's CMakeLists.txt has to also be modified to call add_subdirectory() on LibX.

Having each target call add_subdirectory() on its own dependencies seems silly, because that would create an insane number of duplicated targets. If LibA depends on LibB and LibC, and both LibB and LibC depend on LibD, this approach would result in both LibB and LibC calling add_subdirectory() on LibD, creating the target twice, which would likely not compile.

Are these my only two options? Either:
- use a superbuild to have CMake handle my transitive dependencies, but give up per-application build environment changes, or
- track all transitive dependencies manually in each application's CMakeLists.txt, but retain the ability to change the build environment per application.

From zdenop at gmail.com  Fri Sep 27 16:18:27 2019
From: zdenop at gmail.com (Zdenko Podobny)
Date: Fri, 27 Sep 2019 22:18:27 +0200
Subject: [CMake] printing CMAKE_CXX_FLAGS_* based on build type
Message-ID: <CAJbzG8xQy5vkSP=8ZmL0cnpFoJ+26kOkup4H-ATX4EX+NoCBeg@mail.gmail.com>

Hello,

I try to print  CMAKE_CXX_FLAGS_DEBUG/CMAKE_CXX_FLAGS_RELEASE as one line
statement but is does not work for me:

message( STATUS "CXX compiler ${CMAKE_BUILD_TYPE} build options:
${CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE}}")

Produce empy result, but
message( STATUS "CXX compiler  Release build options:
${CMAKE_CXX_FLAGS_RELEASE}")
works as expected.
Is it possible to do it in one line or I have to use if/elseif ?

Zdenko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190927/8ab2ec0c/attachment.html>

From avraham.shukron at gmail.com  Fri Sep 27 17:22:47 2019
From: avraham.shukron at gmail.com (Avraham Shukron)
Date: Sat, 28 Sep 2019 00:22:47 +0300
Subject: [CMake] Project Structure and add_subdirectory()
In-Reply-To: <CY4PR19MB0102976638002A9F4E14076EEA810@CY4PR19MB0102.namprd19.prod.outlook.com>
References: <CY4PR19MB0102976638002A9F4E14076EEA810@CY4PR19MB0102.namprd19.prod.outlook.com>
Message-ID: <CAJX3zAukBdTkp0fbV6KBSges0X57FcSyUrUwT1imdhXx35-hKA@mail.gmail.com>

I think option 2 (keeping track on transitive dependencies) should be out
of the question.
It is bound to fail.

Superbuild setup makes sense where all the components are part of a bigger
whole.
But if each application may depend on a different "flavor" of  a
dependency library, I think it should be reflected in your project
structure, E.g each application in a separate repository, with all the
dependencies as submodules.

alternatively, you can create a multi-root setup, where you have a
project-root-directory for each application, with a top-level CMakeLists
that adds all the necessary subdirectories.
This way, you get the best of all worlds:
1. Each component's source code is kept only once, and changes are
immediately affecting all products.
2. You can compile each application independently from one another.

Consider the following structure:

-top/
    - app1_root/
        - CMakeLists.txt
    - app2_root/
        - CMakeLists.txt
    - app3_root/
        - CMakeLists.txt
    - components/
        - CMakeLists.txt
        - libA/
        - libB/
        - libC/

The only issue I can think of is that in each application's top-level
CMakeLists.txt you have to add_subdirectory(../components) and the ".." is
kind of ugly.
Other than that I think it should work


On Fri, Sep 27, 2019 at 7:00 PM Marek Vojtko <marek.vojtko at oxidegames.com>
wrote:

> Using add_subdirectory() in a "superbuild" setup is straightforward:
> Create a root CMakeLists.txt which calls add_subdirectory() on all
> directories of your project and each target can then use
> target_link_libraries() without worrying where the target came from.
>
> Unfortunately the "superbuild" setup also means that each target is
> compiled exactly once, which means that you cannot change a target's build
> environment per-application (e.g. preprocessor definitions that change the
> sizes of stack arrays).
>
> If I need per-application control of its dependencies' build environment I
> can have each application's CMakeLists.txt call add_subdirectory() for all
> of its dependencies. However, that means that each application now has to
> know all of its *transitive* dependencies and the application's
> CMakeLists.txt has to be kept up-to-date with any changes in its dependency
> tree, no matter how deep. So if AppA depends on LibA, which depends on
> LibB, which depends on LibC. Not only does AppA's CMakeLists.txt have to
> call add_subdirectory() on LibA, LibB, and LibC, but if LibC is modified to
> depend on LibX, now AppA's CMakeLists.txt has to also be modified to call
> add_subdirectory() on LibX.
>
> Having each target call add_subdirectory() on its own dependencies seems
> silly, because that would create an insane number of duplicated targets. If
> LibA depends on LibB and LibC, and both LibB and LibC depend on LibD, this
> approach would result in both LibB and LibC calling add_subdirectory() on
> LibD, creating the target twice, which would likely not compile.
>
> Are these my only two options? Either:
> - use a superbuild to have CMake handle my transitive dependencies, but
> give up per-application build environment changes, or
> - track all transitive dependencies manually in each application's
> CMakeLists.txt, but retain the ability to change the build environment per
> application.
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190928/6eb6eb5f/attachment.html>

From fdk17 at ftml.net  Fri Sep 27 17:54:29 2019
From: fdk17 at ftml.net (fdk17)
Date: Fri, 27 Sep 2019 17:54:29 -0400
Subject: [CMake] printing CMAKE_CXX_FLAGS_* based on build type
In-Reply-To: <CAJbzG8xQy5vkSP=8ZmL0cnpFoJ+26kOkup4H-ATX4EX+NoCBeg@mail.gmail.com>
References: <CAJbzG8xQy5vkSP=8ZmL0cnpFoJ+26kOkup4H-ATX4EX+NoCBeg@mail.gmail.com>
Message-ID: <48753716-1f66-4fd8-83cd-3ec394063ccb@www.fastmail.com>

Are you using a generator that uses CMAKE_BUILD_TYPE and has it set to a known value? Build type doesn?t have to be set and multi-config generators don?t use it. 

On Fri, Sep 27, 2019, at 4:18 PM, Zdenko Podobny wrote:
> Hello,
> 
> I try to print CMAKE_CXX_FLAGS_DEBUG/CMAKE_CXX_FLAGS_RELEASE as one line statement but is does not work for me:
> 
> message( STATUS "CXX compiler ${CMAKE_BUILD_TYPE} build options: ${CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE}}")
> 
> Produce empy result, but 
> message( STATUS "CXX compiler Release build options: ${CMAKE_CXX_FLAGS_RELEASE}")
> works as expected.
> Is it possible to do it in one line or I have to use if/elseif ?
> 
> Zdenko
> -- 
> 
> 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 services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190927/e67d386c/attachment-0001.html>

From zdenop at gmail.com  Fri Sep 27 18:14:39 2019
From: zdenop at gmail.com (Zdenko Podobny)
Date: Sat, 28 Sep 2019 00:14:39 +0200
Subject: [CMake] printing CMAKE_CXX_FLAGS_* based on build type
In-Reply-To: <48753716-1f66-4fd8-83cd-3ec394063ccb@www.fastmail.com>
References: <CAJbzG8xQy5vkSP=8ZmL0cnpFoJ+26kOkup4H-ATX4EX+NoCBeg@mail.gmail.com>
 <48753716-1f66-4fd8-83cd-3ec394063ccb@www.fastmail.com>
Message-ID: <CAJbzG8xV2ObVMpOSzdwHTQaWWXcowwBy6OWNwoJq2y86DXPioA@mail.gmail.com>

Yes, build type is known (e.g   value of ${CMAKE_BUILD_TYPE}  is shown in
output).  I use command like this:
cmake .. -G Ninja  -DCMAKE_INSTALL_PREFIX=%INSTALL_DIR%
-DCMAKE_PREFIX_PATH=%INSTALL_DIR% -DCMAKE_BUILD_TYPE=Release


Zdenko


pi 27. 9. 2019 o 23:54 fdk17 <fdk17 at ftml.net> nap?sal(a):

> Are you using a generator that uses CMAKE_BUILD_TYPE and has it set to a
> known value?  Build type doesn?t have to be set and multi-config generators
> don?t use it.
>
> On Fri, Sep 27, 2019, at 4:18 PM, Zdenko Podobny wrote:
>
> Hello,
>
> I try to print  CMAKE_CXX_FLAGS_DEBUG/CMAKE_CXX_FLAGS_RELEASE as one line
> statement but is does not work for me:
>
> message( STATUS "CXX compiler ${CMAKE_BUILD_TYPE} build options:
> ${CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE}}")
>
> Produce empy result, but
> message( STATUS "CXX compiler  Release build options:
> ${CMAKE_CXX_FLAGS_RELEASE}")
> works as expected.
> Is it possible to do it in one line or I have to use if/elseif ?
>
> Zdenko
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
>
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190928/f8f3482d/attachment.html>

From marek.vojtko at oxidegames.com  Fri Sep 27 18:38:59 2019
From: marek.vojtko at oxidegames.com (Marek Vojtko)
Date: Fri, 27 Sep 2019 22:38:59 +0000
Subject: [CMake] Project Structure and add_subdirectory()
In-Reply-To: <CAJX3zAukBdTkp0fbV6KBSges0X57FcSyUrUwT1imdhXx35-hKA@mail.gmail.com>
References: <CY4PR19MB0102976638002A9F4E14076EEA810@CY4PR19MB0102.namprd19.prod.outlook.com>
 <CAJX3zAukBdTkp0fbV6KBSges0X57FcSyUrUwT1imdhXx35-hKA@mail.gmail.com>
Message-ID: <CY4PR19MB01021EB9CF4D8F276FAC8216EA810@CY4PR19MB0102.namprd19.prod.outlook.com>

I agree that manually keeping track of transitive dependencies is a very bad and error-prone idea.

The ideal solution is the separate repositories, but I don?t think that?s really feasible.

The multi-root setup would work, but the ugly part of it is requiring an ?app*_root? directory for each application, which is needed to be able to create a solution/makefile with only the application?s dependencies. When compiling an app I don?t want to be compiling targets it does not depend on, which is what would happen if I were to use the app*_root directory directly. So in your example:

-top/
    - app1 /
        - CMakeLists.txt
    - app1_root/
        - CMakeLists.txt
    - app2/
        - CMakeLists.txt
    - app2_root/
        - CMakeLists.txt
    - app3/
        - CMakeLists.txt
    - app3_root/
        - CMakeLists.txt
    - components/
        - CMakeLists.txt
        - libA/
        - libB/
        - libC/

And developers would have to CMake the app*_root directories and then open solutions / run makefiles generated for the individual apps. Not terrible, but definitely not intuitive. But thank you for sharing that, I haven?t thought of that ?

From: Avraham Shukron <avraham.shukron at gmail.com>
Sent: Friday, September 27, 2019 5:23 PM
To: Marek Vojtko <marek.vojtko at oxidegames.com>
Cc: cmake at cmake.org
Subject: Re: [CMake] Project Structure and add_subdirectory()

I think option 2 (keeping track on transitive dependencies) should be out of the question.
It is bound to fail.

Superbuild setup makes sense where all the components are part of a bigger whole.
But if each application may depend on a different "flavor" of  a dependency library, I think it should be reflected in your project structure, E.g each application in a separate repository, with all the dependencies as submodules.

alternatively, you can create a multi-root setup, where you have a project-root-directory for each application, with a top-level CMakeLists that adds all the necessary subdirectories.
This way, you get the best of all worlds:
1. Each component's source code is kept only once, and changes are immediately affecting all products.
2. You can compile each application independently from one another.

Consider the following structure:

-top/
    - app1_root/
        - CMakeLists.txt
    - app2_root/
        - CMakeLists.txt
    - app3_root/
        - CMakeLists.txt
    - components/
        - CMakeLists.txt
        - libA/
        - libB/
        - libC/

The only issue I can think of is that in each application's top-level CMakeLists.txt you have to add_subdirectory(../components) and the ".." is kind of ugly.
Other than that I think it should work


On Fri, Sep 27, 2019 at 7:00 PM Marek Vojtko <marek.vojtko at oxidegames.com<mailto:marek.vojtko at oxidegames.com>> wrote:
Using add_subdirectory() in a "superbuild" setup is straightforward: Create a root CMakeLists.txt which calls add_subdirectory() on all directories of your project and each target can then use target_link_libraries() without worrying where the target came from.

Unfortunately the "superbuild" setup also means that each target is compiled exactly once, which means that you cannot change a target's build environment per-application (e.g. preprocessor definitions that change the sizes of stack arrays).

If I need per-application control of its dependencies' build environment I can have each application's CMakeLists.txt call add_subdirectory() for all of its dependencies. However, that means that each application now has to know all of its *transitive* dependencies and the application's CMakeLists.txt has to be kept up-to-date with any changes in its dependency tree, no matter how deep. So if AppA depends on LibA, which depends on LibB, which depends on LibC. Not only does AppA's CMakeLists.txt have to call add_subdirectory() on LibA, LibB, and LibC, but if LibC is modified to depend on LibX, now AppA's CMakeLists.txt has to also be modified to call add_subdirectory() on LibX.

Having each target call add_subdirectory() on its own dependencies seems silly, because that would create an insane number of duplicated targets. If LibA depends on LibB and LibC, and both LibB and LibC depend on LibD, this approach would result in both LibB and LibC calling add_subdirectory() on LibD, creating the target twice, which would likely not compile.

Are these my only two options? Either:
- use a superbuild to have CMake handle my transitive dependencies, but give up per-application build environment changes, or
- track all transitive dependencies manually in each application's CMakeLists.txt, but retain the ability to change the build environment per application.
--

Powered by www.kitware.com<http://www.kitware.com>

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190927/b7e7020e/attachment-0001.html>

From craig.scott at crascit.com  Fri Sep 27 18:57:18 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Sat, 28 Sep 2019 08:57:18 +1000
Subject: [CMake] printing CMAKE_CXX_FLAGS_* based on build type
In-Reply-To: <CAJbzG8xV2ObVMpOSzdwHTQaWWXcowwBy6OWNwoJq2y86DXPioA@mail.gmail.com>
References: <CAJbzG8xQy5vkSP=8ZmL0cnpFoJ+26kOkup4H-ATX4EX+NoCBeg@mail.gmail.com>
 <48753716-1f66-4fd8-83cd-3ec394063ccb@www.fastmail.com>
 <CAJbzG8xV2ObVMpOSzdwHTQaWWXcowwBy6OWNwoJq2y86DXPioA@mail.gmail.com>
Message-ID: <CA+dygYnGxD3AZVKmBuQV-072iHz5qiVifZ_Qq+sD53vT=p7qEA@mail.gmail.com>

On Sat, Sep 28, 2019 at 8:15 AM Zdenko Podobny <zdenop at gmail.com> wrote:

> Yes, build type is known (e.g   value of ${CMAKE_BUILD_TYPE}  is shown in
> output).  I use command like this:
> cmake .. -G Ninja  -DCMAKE_INSTALL_PREFIX=%INSTALL_DIR%
> -DCMAKE_PREFIX_PATH=%INSTALL_DIR% -DCMAKE_BUILD_TYPE=Release
>
>
> Zdenko
>
>
> pi 27. 9. 2019 o 23:54 fdk17 <fdk17 at ftml.net> nap?sal(a):
>
>> Are you using a generator that uses CMAKE_BUILD_TYPE and has it set to a
>> known value?  Build type doesn?t have to be set and multi-config generators
>> don?t use it.
>>
>> On Fri, Sep 27, 2019, at 4:18 PM, Zdenko Podobny wrote:
>>
>> Hello,
>>
>> I try to print  CMAKE_CXX_FLAGS_DEBUG/CMAKE_CXX_FLAGS_RELEASE as one line
>> statement but is does not work for me:
>>
>> message( STATUS "CXX compiler ${CMAKE_BUILD_TYPE} build options:
>> ${CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE}}")
>>
>>
CMake variable names are case-sensitive. The value of CMAKE_BUILD_TYPE is
likely not all uppercase, so ${CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE}} will
almost certainly end up naming a variable that isn't defined.

Also, as fdk17 has already mentioned, CMAKE_BUILD_TYPE isn't always
defined. For multi-configuration generators (e.g. Visual Studio, Xcode), it
typically won't be defined and if it was, it would be meaningless. If you
have logic switching on CMAKE_BUILD_TYPE, it is usually a sign you are
trying to do something you shouldn't (or that you explicitly don't support
multi-config generators).



>
>> Produce empy result, but
>> message( STATUS "CXX compiler  Release build options:
>> ${CMAKE_CXX_FLAGS_RELEASE}")
>> works as expected.
>> Is it possible to do it in one line or I have to use if/elseif ?
>>
>> Zdenko
>>
>>

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
Consulting services (CMake, C++, build/release processes):
https://crascit.com/services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190928/ab5de932/attachment.html>

From melak47 at posteo.net  Fri Sep 27 23:24:45 2019
From: melak47 at posteo.net (melak47)
Date: Sat, 28 Sep 2019 05:24:45 +0200
Subject: [CMake] Ninja generator emits order-only dependencies for custom
 commands
Message-ID: <1a477845-6e0a-a380-9aa2-286630bb1ee8@posteo.net>

I'm using add_custom_command with the Ninja generator on Windows to
invoke mc.exe on an .mc file,
to generate an .rc file, to create a resource DLL.
The full example is here:
https://gist.github.com/melak47/f7d83046c6d57b338d633468d078f5b1

The problem is, changing the .mc file and rebuilding only causes mc.exe
to rerun,
anything depending on the generated .rc file is not rebuilt.
I think this happens because cmake generates some order-only
dependencies for the generated files.

Some of the relevant build statements that are generated:


#
=============================================================================
# Object build statements for MODULE_LIBRARY target example


#############################################
# Order-only phony target for example

build cmake_object_order_depends_target_example: phony || example.hpp
example.rc example_MSG00001.bin

build CMakeFiles\example.dir\example.rc.res: RC_COMPILER__example
D$:\repro\build\example.rc || cmake_object_order_depends_target_example
  DEFINES = -Dexample_EXPORTS
  DEP_FILE = CMakeFiles\example.dir\example.rc.res.d
  FLAGS = -DWIN32 -D_DEBUG
  OBJECT_DIR = CMakeFiles\example.dir
  OBJECT_FILE_DIR = CMakeFiles\example.dir
  TARGET_COMPILE_PDB = CMakeFiles\example.dir\
  TARGET_PDB = example.pdb


#
=============================================================================
# Link build statements for MODULE_LIBRARY target example


#############################################
# Link the shared module example.dll

build example.dll: CXX_MODULE_LIBRARY_LINKER__example
CMakeFiles\example.dir\example.rc.res
  LANGUAGE_COMPILE_FLAGS = /DWIN32 /D_WINDOWS /GR /EHsc /Zi /Ob0 /Od
/RTC1 -MDd
  LINK_FLAGS = /machine:x64 /debug /INCREMENTAL  /noentry
  LINK_LIBRARIES = kernel32.lib user32.lib gdi32.lib winspool.lib
shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
  OBJECT_DIR = CMakeFiles\example.dir
  POST_BUILD = cd .
  PRE_LINK = cd .
  TARGET_COMPILE_PDB = CMakeFiles\example.dir\
  TARGET_FILE = example.dll
  TARGET_IMPLIB = example.lib
  TARGET_PDB = example.pdb


#############################################
# Custom command for example.rc

build example.rc example.hpp example_MSG00001.bin: CUSTOM_COMMAND
..\example.mc
  COMMAND = cmd.exe /C "cd /D D:\repro\build && "C:\Program Files
(x86)\Windows Kits\10\bin\10.0.18362.0\x64\mc.exe" -b -e hpp -h
D:/repro/build -r D:/repro/build D:/repro/example.mc"
  DESC = Generating example.rc, example.hpp, example_MSG00001.bin
  restat = 1


#############################################
# Assume dependencies for generated source file.

build D$:\repro\build\example.rc: CUSTOM_COMMAND ||
cmake_object_order_depends_target_example
  COMMAND = cmd.exe /c
  restat = 1


As you can see, CMakeFiles\example.dir\example.rc.res depends on
D$:\repro\build\example.rc,
which depends on the actual example.rc through
cmake_object_order_depends_target_example as
an **order-only** dependency.
If I read the ninja manual correctly, this means changes to example.rc
will by design not cause depndees to be rebuilt.

If instead of an empty CUSTOM_COMMAND, cmake emitted a phony like:

build D$:\repro\build\example.rc: phony example.rc

example.rc.res and example.dll would be properly rebuilt.
(Also, a phony does not appear in the build log, unlike the empty
CUSTOM_COMMAND which just shows up as 'cmd /c')

Is this a bug, or is there some intent behind emitting a CUSTOM_COMMAND
here?

From avraham.shukron at gmail.com  Sat Sep 28 02:10:36 2019
From: avraham.shukron at gmail.com (Avraham Shukron)
Date: Sat, 28 Sep 2019 09:10:36 +0300
Subject: [CMake] Project Structure and add_subdirectory()
In-Reply-To: <CY4PR19MB01021EB9CF4D8F276FAC8216EA810@CY4PR19MB0102.namprd19.prod.outlook.com>
References: <CY4PR19MB0102976638002A9F4E14076EEA810@CY4PR19MB0102.namprd19.prod.outlook.com>
 <CAJX3zAukBdTkp0fbV6KBSges0X57FcSyUrUwT1imdhXx35-hKA@mail.gmail.com>
 <CY4PR19MB01021EB9CF4D8F276FAC8216EA810@CY4PR19MB0102.namprd19.prod.outlook.com>
Message-ID: <CAJX3zAtvRp=s8ETS1zGORwrfQAaVPKvhLSMuH4K=2fxtcEkZ0w@mail.gmail.com>

On Sat, Sep 28, 2019 at 1:39 AM Marek Vojtko <marek.vojtko at oxidegames.com>
wrote:

> I agree that manually keeping track of transitive dependencies is a very
> bad and error-prone idea.
>
>
>
> The ideal solution is the separate repositories, but I don?t think that?s
> really feasible.
>
>
>
> The multi-root setup would work, but the ugly part of it is requiring an
> ?app*_root? directory for each application, which is needed to be able to
> create a solution/makefile with only the application?s dependencies. When
> compiling an app I don?t want to be compiling targets it does not depend
> on, which is what would happen if I were to use the app*_root directory
> directly.
>

Why would you build targets you don't depend upon in my original proposal?
you certainly *include* them all in your project, but as long as you build
your application target, only it's actual dependencies will be built. Of
course, if you build the "all" target, everything will be built, but that
could easily be avoided with EXCLUDE_FROM_ALL when adding the `components`
subdirectory.?


>
> *From:* Avraham Shukron <avraham.shukron at gmail.com>
> *Sent:* Friday, September 27, 2019 5:23 PM
> *To:* Marek Vojtko <marek.vojtko at oxidegames.com>
> *Cc:* cmake at cmake.org
> *Subject:* Re: [CMake] Project Structure and add_subdirectory()
>
>
>
> I think option 2 (keeping track on transitive dependencies) should be out
> of the question.
>
> It is bound to fail.
>
>
>
> Superbuild setup makes sense where all the components are part of a bigger
> whole.
>
> But if each application may depend on a different "flavor" of  a
> dependency library, I think it should be reflected in your project
> structure, E.g each application in a separate repository, with all the
> dependencies as submodules.
>
>
>
> alternatively, you can create a multi-root setup, where you have a
> project-root-directory for each application, with a top-level CMakeLists
> that adds all the necessary subdirectories.
>
> This way, you get the best of all worlds:
>
> 1. Each component's source code is kept only once, and changes are
> immediately affecting all products.
>
> 2. You can compile each application independently from one another.
>
>
>
> Consider the following structure:
>
>
>
> -top/
>
>     - app1_root/
>
>         - CMakeLists.txt
>
>     - app2_root/
>
>         - CMakeLists.txt
>
>     - app3_root/
>
>         - CMakeLists.txt
>
>     - components/
>
>         - CMakeLists.txt
>
>         - libA/
>
>         - libB/
>
>         - libC/
>
>
>
> The only issue I can think of is that in each application's top-level
> CMakeLists.txt you have to add_subdirectory(../components) and the ".." is
> kind of ugly.
>
> Other than that I think it should work
>
>
>
>
>
> On Fri, Sep 27, 2019 at 7:00 PM Marek Vojtko <marek.vojtko at oxidegames.com>
> wrote:
>
> Using add_subdirectory() in a "superbuild" setup is straightforward:
> Create a root CMakeLists.txt which calls add_subdirectory() on all
> directories of your project and each target can then use
> target_link_libraries() without worrying where the target came from.
>
> Unfortunately the "superbuild" setup also means that each target is
> compiled exactly once, which means that you cannot change a target's build
> environment per-application (e.g. preprocessor definitions that change the
> sizes of stack arrays).
>
> If I need per-application control of its dependencies' build environment I
> can have each application's CMakeLists.txt call add_subdirectory() for all
> of its dependencies. However, that means that each application now has to
> know all of its *transitive* dependencies and the application's
> CMakeLists.txt has to be kept up-to-date with any changes in its dependency
> tree, no matter how deep. So if AppA depends on LibA, which depends on
> LibB, which depends on LibC. Not only does AppA's CMakeLists.txt have to
> call add_subdirectory() on LibA, LibB, and LibC, but if LibC is modified to
> depend on LibX, now AppA's CMakeLists.txt has to also be modified to call
> add_subdirectory() on LibX.
>
> Having each target call add_subdirectory() on its own dependencies seems
> silly, because that would create an insane number of duplicated targets. If
> LibA depends on LibB and LibC, and both LibB and LibC depend on LibD, this
> approach would result in both LibB and LibC calling add_subdirectory() on
> LibD, creating the target twice, which would likely not compile.
>
> Are these my only two options? Either:
> - use a superbuild to have CMake handle my transitive dependencies, but
> give up per-application build environment changes, or
> - track all transitive dependencies manually in each application's
> CMakeLists.txt, but retain the ability to change the build environment per
> application.
> --
>
> 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 services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190928/c2870646/attachment-0001.html>

From craig.scott at crascit.com  Sat Sep 28 02:27:50 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Sat, 28 Sep 2019 16:27:50 +1000
Subject: [CMake] Ninja generator emits order-only dependencies for
 custom commands
In-Reply-To: <1a477845-6e0a-a380-9aa2-286630bb1ee8@posteo.net>
References: <1a477845-6e0a-a380-9aa2-286630bb1ee8@posteo.net>
Message-ID: <CA+dygY=wNN_bKrHQKSKfQt7VLC77OtBK7OWANVn9UW6kc344pw@mail.gmail.com>

On Sat, Sep 28, 2019 at 1:31 PM melak47 <melak47 at posteo.net> wrote:

> I'm using add_custom_command with the Ninja generator on Windows to
> invoke mc.exe on an .mc file,
> to generate an .rc file, to create a resource DLL.
> The full example is here:
> https://gist.github.com/melak47/f7d83046c6d57b338d633468d078f5b1
>
> The problem is, changing the .mc file and rebuilding only causes mc.exe
> to rerun,
> anything depending on the generated .rc file is not rebuilt.
> I think this happens because cmake generates some order-only
> dependencies for the generated files.
>
> Some of the relevant build statements that are generated:
>
>
> #
>
> =============================================================================
> # Object build statements for MODULE_LIBRARY target example
>
>
> #############################################
> # Order-only phony target for example
>
> build cmake_object_order_depends_target_example: phony || example.hpp
> example.rc example_MSG00001.bin
>
> build CMakeFiles\example.dir\example.rc.res: RC_COMPILER__example
> D$:\repro\build\example.rc || cmake_object_order_depends_target_example
>   DEFINES = -Dexample_EXPORTS
>   DEP_FILE = CMakeFiles\example.dir\example.rc.res.d
>   FLAGS = -DWIN32 -D_DEBUG
>   OBJECT_DIR = CMakeFiles\example.dir
>   OBJECT_FILE_DIR = CMakeFiles\example.dir
>   TARGET_COMPILE_PDB = CMakeFiles\example.dir\
>   TARGET_PDB = example.pdb
>
>
> #
>
> =============================================================================
> # Link build statements for MODULE_LIBRARY target example
>
>
> #############################################
> # Link the shared module example.dll
>
> build example.dll: CXX_MODULE_LIBRARY_LINKER__example
> CMakeFiles\example.dir\example.rc.res
>   LANGUAGE_COMPILE_FLAGS = /DWIN32 /D_WINDOWS /GR /EHsc /Zi /Ob0 /Od
> /RTC1 -MDd
>   LINK_FLAGS = /machine:x64 /debug /INCREMENTAL  /noentry
>   LINK_LIBRARIES = kernel32.lib user32.lib gdi32.lib winspool.lib
> shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
>   OBJECT_DIR = CMakeFiles\example.dir
>   POST_BUILD = cd .
>   PRE_LINK = cd .
>   TARGET_COMPILE_PDB = CMakeFiles\example.dir\
>   TARGET_FILE = example.dll
>   TARGET_IMPLIB = example.lib
>   TARGET_PDB = example.pdb
>
>
> #############################################
> # Custom command for example.rc
>
> build example.rc example.hpp example_MSG00001.bin: CUSTOM_COMMAND
> ..\example.mc
>   COMMAND = cmd.exe /C "cd /D D:\repro\build && "C:\Program Files
> (x86)\Windows Kits\10\bin\10.0.18362.0\x64\mc.exe" -b -e hpp -h
> D:/repro/build -r D:/repro/build D:/repro/example.mc"
>   DESC = Generating example.rc, example.hpp, example_MSG00001.bin
>   restat = 1
>
>
> #############################################
> # Assume dependencies for generated source file.
>
> build D$:\repro\build\example.rc: CUSTOM_COMMAND ||
> cmake_object_order_depends_target_example
>   COMMAND = cmd.exe /c
>   restat = 1
>
>
> As you can see, CMakeFiles\example.dir\example.rc.res depends on
> D$:\repro\build\example.rc,
> which depends on the actual example.rc through
> cmake_object_order_depends_target_example as
> an **order-only** dependency.
> If I read the ninja manual correctly, this means changes to example.rc
> will by design not cause depndees to be rebuilt.
>
> If instead of an empty CUSTOM_COMMAND, cmake emitted a phony like:
>
> build D$:\repro\build\example.rc: phony example.rc
>
> example.rc.res and example.dll would be properly rebuilt.
> (Also, a phony does not appear in the build log, unlike the empty
> CUSTOM_COMMAND which just shows up as 'cmd /c')
>
> Is this a bug, or is there some intent behind emitting a CUSTOM_COMMAND
> here?
>


This seems like a bug to me, please add it to gitlab as a new issue here:

https://gitlab.kitware.com/cmake/cmake/issues

Please ensure you also record what version of CMake you are using. If you
can test with some different CMake versions to confirm whether it is a
long-standing issue or a regression in a more recent version, that would
also be very helpful. I believe there have been a few changes relating to
RC handling in the last few releases, so can't rule out a regression.


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
Consulting services (CMake, C++, build/release processes):
https://crascit.com/services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190928/add3b136/attachment.html>

From stefan at seefeld.name  Sat Sep 28 16:38:02 2019
From: stefan at seefeld.name (Stefan Seefeld)
Date: Sat, 28 Sep 2019 16:38:02 -0400
Subject: [CMake] using `install()` with EXPORT and COMPONENT
Message-ID: <f700b954-a306-6c6c-9d44-7ab5b5570402@seefeld.name>

Hello,

I'm working on a library project that will be packaged in multiple 
components. A "runtime" component will contain the (shared) library, an 
a "dev" component the associated headers (and perhaps other 
development-only artefacts).

I have successfully used the `install()` command to install these two 
sets of artefacts, i.e. calling `install(... COMPONENT runtime)`, as 
well as `install(... COMPONENT dev)`.

However, I'm now looking into calling `install(TARGETS ... EXPORT ...)`. 
The documentation explains how the list of installed headerfiles can 
actually be inferred from the target itself (if the 
target_include_directories have been appropriately set). However, I 
can't call that function more than once on the same target, and thus I 
seem to have no way to split the installation into multiple components.

Does anyone know what I'm missing ? What is the suggested way to package 
a project into the usual "runtime" and "dev" components ?

Many thanks,

Stefan
-- 

       ...ich hab' noch einen Koffer in Berlin...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190928/5d228102/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .signature.png
Type: image/png
Size: 2754 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190928/5d228102/attachment.png>

From craig.scott at crascit.com  Sun Sep 29 05:13:05 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Sun, 29 Sep 2019 19:13:05 +1000
Subject: [CMake] using `install()` with EXPORT and COMPONENT
In-Reply-To: <f700b954-a306-6c6c-9d44-7ab5b5570402@seefeld.name>
References: <f700b954-a306-6c6c-9d44-7ab5b5570402@seefeld.name>
Message-ID: <CA+dygY=qaUHf+1b69KRqyUfXwq3uX313Rc2s1o8awfEg_=DVmw@mail.gmail.com>

On Sun, Sep 29, 2019 at 6:38 AM Stefan Seefeld <stefan at seefeld.name> wrote:

> Hello,
>
> I'm working on a library project that will be packaged in multiple
> components. A "runtime" component will contain the (shared) library, an a
> "dev" component the associated headers (and perhaps other development-only
> artefacts).
>
> I have successfully used the `install()` command to install these two sets
> of artefacts, i.e. calling `install(... COMPONENT runtime)`, as well as
> `install(... COMPONENT dev)`.
>
> However, I'm now looking into calling `install(TARGETS ... EXPORT ...)`.
> The documentation explains how the list of installed headerfiles can
> actually be inferred from the target itself (if the
> target_include_directories have been appropriately set). However, I can't
> call that function more than once on the same target, and thus I seem to
> have no way to split the installation into multiple components.
>
> Does anyone know what I'm missing ? What is the suggested way to package a
> project into the usual "runtime" and "dev" components ?
>

If all of your headers should be installed to a single directory, then you
can list the headers in the target's PUBLIC_HEADER or PRIVATE_HEADER target
property, then make sure you add those destinations in the install(TARGETS
...) command. For example:

include(GNUInstallDirs)
install(TARGETS myLib
    EXPORT SomeProj_Targets
    RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
            COMPONENT SomeProj_Runtime
    LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
            COMPONENT          SomeProj_Runtime
            NAMELINK_COMPONENT SomeProj_Development   # Requires CMake 3.12
    ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
            COMPONENT SomeProj_Development
    PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
            COMPONENT SomeProj_Development
    INCLUDES DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
)

If you need to install headers into more than one directory (i.e. your
headers have some sort of directory hierarchy), then the above doesn't work
because it flattens all of the headers into a single location. Instead, you
have to use install(FILES ...) to install the headers directly for such
cases. Also, the target_include_directories() command has nothing to do
with what header files get installed. Rather, it only controls the header
search paths attached to a target.

FYI, part of my CppCon talk "Deep CMake For Library Authors" from a couple
of weeks ago has a fair amount of overlap with this topic (specifically
install components and destinations). I'm waiting for the YouTube clip to
be made available and then I'll be posting a blog article on my website
with links and the slides. When it goes up, you'll be able to find it at
https://crascit.com (hopefully sometime this week, but depends how quickly
the production people get the video done).


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
Consulting services (CMake, C++, build/release processes):
https://crascit.com/services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190929/f18e4966/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .signature.png
Type: image/png
Size: 2754 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190929/f18e4966/attachment.png>

From stefan at seefeld.name  Sun Sep 29 14:09:20 2019
From: stefan at seefeld.name (Stefan Seefeld)
Date: Sun, 29 Sep 2019 14:09:20 -0400
Subject: [CMake] using `install()` with EXPORT and COMPONENT
In-Reply-To: <CA+dygY=qaUHf+1b69KRqyUfXwq3uX313Rc2s1o8awfEg_=DVmw@mail.gmail.com>
References: <f700b954-a306-6c6c-9d44-7ab5b5570402@seefeld.name>
 <CA+dygY=qaUHf+1b69KRqyUfXwq3uX313Rc2s1o8awfEg_=DVmw@mail.gmail.com>
Message-ID: <65428cf5-f394-c16e-998b-b21fc5f8f477@seefeld.name>

Hi Craig,

thanks for the detailed explanation !

On 2019-09-29 5:13 a.m., Craig Scott wrote:
>
> If all of your headers should be installed to a single directory, then 
> you can list the headers in the target's PUBLIC_HEADER or 
> PRIVATE_HEADER target property, then make sure you add those 
> destinations in the install(TARGETS ...) command. For example:
>
> include(GNUInstallDirs)
> install(TARGETS myLib
> ? ? EXPORT SomeProj_Targets
> ? ? RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
> ? ? ? ? ? ? COMPONENT SomeProj_Runtime
> ? ? LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
> ? ? ? ? ? ? COMPONENT ? ? ? ? ?SomeProj_Runtime
> NAMELINK_COMPONENT SomeProj_Development ? # Requires CMake 3.12
> ? ? ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
> ? ? ? ? ? ? COMPONENT SomeProj_Development
> ? ? PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
> ? ? ? ? ? ? COMPONENT SomeProj_Development
> ? ? INCLUDES DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
> )

I hadn't noticed one can have multiple 'COMPONENT' sections in a single 
`install` call. The CMake documentation could be a bit more clear about 
that.

>
> If you need to install headers into more than one directory (i.e. your 
> headers have some sort of directory hierarchy), then the above doesn't 
> work because it flattens all of the headers into a single location. 
> Instead, you have to use install(FILES ...) to install the headers 
> directly for such cases. Also, the 
> target_include_directories()?command has nothing to do with what 
> header files get installed. Rather, it only controls the header search 
> paths attached to a target.

Right, true.

> FYI, part of my CppCon talk "Deep CMake For Library Authors" from a 
> couple of weeks ago has a fair amount of overlap with this topic 
> (specifically install components and destinations). I'm waiting for 
> the YouTube clip to be made available and then I'll be posting a blog 
> article on my website with links and the slides. When it goes up, 
> you'll be able to find it at https://crascit.com?(hopefully sometime 
> this week, but depends how quickly the production people get the video 
> done).

Great, looking forward to reading the slides.

Many thanks !

Stefan
-- 

       ...ich hab' noch einen Koffer in Berlin...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190929/299b9bb8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .signature.png
Type: image/png
Size: 2754 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190929/299b9bb8/attachment.png>

From doenges at mvtec.com  Mon Sep 30 01:39:34 2019
From: doenges at mvtec.com (Eric Doenges)
Date: Mon, 30 Sep 2019 07:39:34 +0200
Subject: [CMake] printing CMAKE_CXX_FLAGS_* based on build type
In-Reply-To: <CAJbzG8xQy5vkSP=8ZmL0cnpFoJ+26kOkup4H-ATX4EX+NoCBeg@mail.gmail.com>
References: <CAJbzG8xQy5vkSP=8ZmL0cnpFoJ+26kOkup4H-ATX4EX+NoCBeg@mail.gmail.com>
Message-ID: <322ef3d1-8685-a6a8-7ac2-3e7dc8d44e20@mvtec.com>

Unfortunately, the standard values for CMAKE_BUILD_TYPE only have their 
first letter capitalized, i.e. for a release build CMAKE_BUILD_TYPE will 
normally be "Release". To use it like you want to, it would need to be 
"RELEASE". To get around this problem, we define an all upper-case 
BUILD_TYPE in our projects, i.e.:

string(TOUPPER ${CMAKE_BUILD_TYPE} BUILD_TYPE)
message(STATUS "CXX compiler ${CMAKE_BUILD_TYPE} build options: 
${CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE}}")

If you do this, keep in mind what fdk17 said - CMAKE_BUILD_TYPE may not 
be set depending on the generator you use.

Am 27.09.19 um 22:18 schrieb Zdenko Podobny:
> Hello,
>
> I try to print CMAKE_CXX_FLAGS_DEBUG/CMAKE_CXX_FLAGS_RELEASE as one 
> line statement but is does not work for me:
>
> message( STATUS "CXX compiler ${CMAKE_BUILD_TYPE} build options: 
> ${CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE}}")
>
> Produce empy result, but
> message( STATUS "CXX compiler ?Release build options: 
> ${CMAKE_CXX_FLAGS_RELEASE}")
> works as expected.
> Is it possible to do it in one line or I have to use if/elseif ?
>
> Zdenko
>
-- 

*Dr. Eric D?nges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doenges at mvtec.com <mailto:mustermann at mvtec.com> | Tel: +49 89 457 695-0 
| www.mvtec.com <http://www.mvtec.com>

Find our privacy policy here <https://www.mvtec.com/imprint>.

Sign up <https://www.mvtec.com/newsletter> for our MVTec Newsletter!

Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht M?nchen HRB 114695

MVTec Software GmbH Logo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190930/b3520a29/attachment.html>

From marek.vojtko at oxidegames.com  Mon Sep 30 11:01:45 2019
From: marek.vojtko at oxidegames.com (Marek Vojtko)
Date: Mon, 30 Sep 2019 15:01:45 +0000
Subject: [CMake] Project Structure and add_subdirectory()
In-Reply-To: <CAJX3zAtvRp=s8ETS1zGORwrfQAaVPKvhLSMuH4K=2fxtcEkZ0w@mail.gmail.com>
References: <CY4PR19MB0102976638002A9F4E14076EEA810@CY4PR19MB0102.namprd19.prod.outlook.com>
 <CAJX3zAukBdTkp0fbV6KBSges0X57FcSyUrUwT1imdhXx35-hKA@mail.gmail.com>
 <CY4PR19MB01021EB9CF4D8F276FAC8216EA810@CY4PR19MB0102.namprd19.prod.outlook.com>
 <CAJX3zAtvRp=s8ETS1zGORwrfQAaVPKvhLSMuH4K=2fxtcEkZ0w@mail.gmail.com>
Message-ID: <CY4PR19MB0102200B57048A65A7D82C7AEA820@CY4PR19MB0102.namprd19.prod.outlook.com>

> Why would you build targets you don't depend upon in my original proposal? you certainly include them all in your project, but as long as you build your application target, only it's actual dependencies will be built. Of course, if you build the "all" target, everything will be built, but that could easily be avoided with EXCLUDE_FROM_ALL when adding the `components` subdirectory.?

Unfortunately, we?re using Visual Studio, which makes it very easy to ?Build Solution? (which builds all targets, including the CMake-provided ALL_BUILD target), but more cumbersome to build just the application target. There is a default shortcut key for ?Build Solution,? but to build just the application you have to use the UI menus :(

Even if the EXCLUDE_FROM_ALL worked ? again, I believe Visual Studio?s ?Build Solution? just builds all Visual Studio projects that are part of the solution, regardless of what ALL_BUILD does ? having to track which libraries should be excluded from the ALL_BUILD target for each application boils down to manually tracking transitive dependencies ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190930/e7413664/attachment-0001.html>