[CMake] cmake, ccache, CCACHE_BASEDIR: wrong paths in compiler error messages

[Steffen Dettmer]

Hi,

I hope I can still post here? I don't have a "discourse" account.

Let me summarize what we have here. We have projects with some
hunderds CMakeLists.txt. The "main" typically use several
add_subdirectory directives for the use libraries in form of:

  add_subdirectory(${path_lib_a} liba)

For each, cmake creates a subdirectory (such as here "liba") in the
build directory. Normally cmake uses absolute paths, so compiler error
messages contain absolute paths as well.

Now we are also using ccache. Since we use the same libs in many
places, of course we want to share the ccache results. For multiple
builddirs I was not able to get it working, but at least for the case
of multiple sourcedirs that have there builddirs below. This is useful
if several people work on same code (shared ccache) or if you have
several checkouts, for example for similar variants or source code
branches. In most of these cases, many libraries are the same, so
caching in theory should be very effective.

Since ccache also compares compiler arguments of course and it's
include arguments include absolute paths, ccaching across src trees
does not work, so we have to set CCACHE_BASEDIR. Technically cmake
creates a wrapper file used as CMAKE_CXX_COMPILER_LAUNCHER in BUILDDIR
with "export CCACHE_BASEDIR=$TOPSRCDIR" and then calling essentially
"ccache $CXX "$@"". Now ccache works fine across source trees. At the
end of the mail some cmake excerpt in case it is useful.

But unfortunately now IDEs (like Vim, QTCreator...) are unable to jump
to compiler errors, because now the paths are relative to the
directory where the compiler (wrapper) is called. Normally the IDEs
know this from make output:

  make[2]: Entering directory
'/home/sdettmer/work/tisc-src/build/cmake-build-debug-1810'

but unfortunately for "add_subdirectory", cmake uses some own logic
visible only when running make VERBOSE=1, which looks like:

  make[2]: Entering directory
'/home/sdettmer/work/tisc-src/build/cmake-build-debug-1810'
  [ 14%] Building CXX object
  cd /home/sdettmer/work/tisc-src/build/cmake-build-debug-1810/libA
&& /home/sdettmer/work/tisc-src/build/cmake-build-debug-1810/ccache-CXX
/opt/bt/cross/i586-pc-linux-gnu/gcc-4.4.3/usr/bin/i586-pc-linux-gnu-g++
...
-o CMakeFiles/libA.dir/home/sdettmer/work/tisc-src/.../libA/src/File1.cpp.o
 -c /home/sdettmer/work/tisc-src/.../libA /src/File1.cpp


Compiler errrors now are not relative to the path told by make (here
cmake-build-debug-1810), but relative to the "cd .../libA", which is
normally not even visible:

  In file included from ../.././libA/File1.cpp:10: 

Now the IDE looks for path relative to cmake-build-debug-1810, because
it does not know about the "cd ...cmake-build-debug-1810/libA" and
does not find the file.

We discussed this in the team, I searched the web for several hours
now, but I don't find any solution. Due to the absolute paths
requirement of cmake I think I must use CCACHE_BASEDIR, but when I do,
IDEs don't find the files. I didn't find a way to make cmake output
"Entering directory" lines. Since we are probably not the only ones
who use cmake and ccache, we probably doing it wrong and miss an
important point.

How is ccache supposed to be used correctly? I saw many examples in
the internet, but none seem to correctly work with CCACHE_BASEDIR, and
without CCACHE_BASEDIR cache is not efficient and almost useless and
shared cache even completely useless (never hits).

Any help appreciated!

As only workaround we could find, I now manually add:

  echo "make[77]: Entering directory '$(pwd)'"

in the ccache-wrapper. This helps a bit, but generates heaps of output
(entering line for each single file) and I think it breaks when using
"make -j".

Steffen

CMakeLists.txt excerpt:

foreach(_BT_LANG "C" "CXX")
file(WRITE "${CMAKE_BINARY_DIR}/ccache-${_BT_LANG}" ""
"#!/bin/sh\n"
"# Xcode generator doesn't include the compiler as the
first arg:\n"
"[ \"$1\" = \"${CMAKE_${_BT_LANG}_COMPILER}\" ] && shift\n"
"\n"
"# \"Convert\" cmake variable to an env to allow
shared caches\n"
"export CCACHE_BASEDIR=${_BT_CCACHE_BASEDIR}\n"
"export CCACHE_SLOPPINESS=file_macro,time_macros\n"
"# export CCACHE_NODIRECT=set\n"
"export CCACHE_CPP2=set\n"
"[ \"\$VERBOSE\" ] && echo \"make[\${MAKELEVEL:-1}]:
Entering directory '$(pwd)'\"\n"
"\"${_BT_${_BT_LANG}_LAUNCHER}\"
\"${CMAKE_${_BT_LANG}_COMPILER}\" \"$@\"\n"
"[ \"\$VERBOSE\" ] && echo \"make[\${MAKELEVEL:-1}]:
Leaving directory '$(pwd)'\"\n"
)
execute_process(COMMAND chmod a+rx
"${CMAKE_BINARY_DIR}/ccache-${_BT_LANG}")
endforeach()
...
CHECK_CXX_COMPILER_FLAG(-fdiagnostics-color=auto
CXX_FLAG_DIAGNOSTIC_COLOR_AUTO)
if 

[CMake] cmake config. error

[St.Trzaska]

gw32;Configured with: ../gcc-9.2.0/configure --prefix=/mingw64 
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include 
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 
--with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++ 
--enable-shared --enable-static --enable-libatomic --enable-threads=posix 
--enable-graphite --enable-fully-dynamic-string 
--enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes 
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check 
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release 
--disable-rpath --disable-win32-registry --disable-nls --disable-werror 
--disable-symvers --enable-plugin --with-libiconv --with-system-zlib 
--with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 
--with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' 
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as 
--with-gnu-ld;Thread model: posix;gcc version 9.2.0 (Rev2, Built by 
MSYS2 project) 
;COMPILER_PATH=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/;C:/msys64/mingw64/bin/../lib/gcc/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/;LIBRARY_PATH=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/;C:/msys64/mingw64/bin/../lib/gcc/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib/../lib/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../lib/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../;COLLECT_GCC_OPTIONS='-v'
 '-o' 'cmTC_3114e.exe' '-mtune=generic' '-march=x86-64'; 
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/collect2.exe -plugin 
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/liblto_plugin-0.dll 
-plugin-opt=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/lto-wrapper.exe
 -plugin-opt=-fresolution=C:\msys64\tmp\ccrQjewk.res 
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc 
-plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname 
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt 
-plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32 
-plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 
-plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32 
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh 
-plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex 
-plugin-opt=-pass-through=-lmsvcrt -m i386pep -Bdynamic -o cmTC_3114e.exe 
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o
 C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/crtbegin.o 
-LC:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0 
-LC:/msys64/mingw64/bin/../lib/gcc 
-LC:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib/../lib
 -LC:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../lib 
-LC:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib
 -LC:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../.. 
CMakeFiles/cmTC_3114e.dir/CMakeCXXCompilerABI.cpp.obj -lmingw32 -lgcc -lgcc_eh 
-lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32 -lshell32 -luser32 
-lkernel32 -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt 
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib/../lib/default-manifest.o
 
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/crtend.o;COLLECT_GCC_OPTIONS='-v'
 '-o' 'cmTC_3114e.exe' '-mtune=generic' '-march=x86-64';make[1]: 
Leaving directory '/opt/GTest/mybuild/CMakeFiles/CMakeTmp';;]
  implicit libs: []
  implicit dirs: []
  implicit fwks: []



stt@MSI-AMG MINGW64 /opt/GTest
$ pwd
/opt/GTest

stt@MSI-AMG MINGW64 /opt/GTest
$ mkdir mybuild

stt@MSI-AMG MINGW64 /opt/GTest
$ cd mybuild/

stt@MSI-AMG MINGW64 /opt/GTest/mybuild
$ cmake ../
-- The C compiler identification is GNU 9.2.0
-- The CXX compiler identification is GNU 9.2.0
System is unknown to cmake, create:
Platform/MINGW64_NT-10.0-18362 to use this system, please send your config file 
to cm...@www.cmake.org so it can be added to cmake
-- Check for working C compiler: /mingw64/bin/cc.exe
System is unknown to cmake, create:
Platform/MINGW64_NT-10.0-18362 to use this system, please send your config file 
to cm...@www.cmake.org so it can be added to cmake
-- Check for working C compiler: /mingw64/bin/cc.exe -- works
-- Detecting C compiler ABI info
System is unknown to cmake, create:
Platform/MINGW64_NT-10.0-18362 to use this system, please send your config file 
to cm

Re: [CMake] [cmake-developers] productbuild: Installing to absolute system path or to user home path

[Roman Wüger]

Ok if someone is interested I solved it with a post-install script at the 
moment. I installed it in the default location and moved it afterwards with the 
post-install script to the ~/Library...

Regards
Roman

> Am 05.11.2019 um 15:02 schrieb Roman Wüger :
> 
> 
> Hello,
> 
> The main wish is to install to the user directory as described in the 
> documentation, the absolute path to the „all users“ works already:
> 
> Here is the description from the manual, also attached as an image
> 
> Automatic plug-in loading
> Lightroom automatically checks for plug-ins in the standard Modules folder 
> where other Lightroom settings are stored:
>In Mac OS (current user) In Mac OS (all users)
> In Windows XP
> plug-in and also installs a helper application.
> Plug-ins that are installed in this location are automatically listed in the 
> Plug-in Manager dialog. You can use the dialog to enable or disable such a 
> plug-in, but not to remove it. The Remove button is dimmed when such a 
> plug-in is selected.
> ~/Library/Application Support/Adobe/Lightroom/Modules /Library/Application 
> Support/Adobe/Lightroom/Modules
> C:\Documents and Users\username\Application Data\Adobe\Lightroom\Modules
> C:\Users\username\AppData\Roaming\Adobe\Lightroom\Modules You may want to use 
> this location if, for example, you are writing an installer that installs a 
> Lightroom
>In Windows 7/Vista
> 
> 
> 
> 
> Regards
> Roman
> 
>>> Am 01.11.2019 um 05:10 schrieb David Aguilar :
>>> 
>> 
>> I would also suggest avoiding absolute paths so that the user can tell you 
>> where to root the installation.
>> 
>> One way to do that is to use GNUInstallDirs so that the user can specify the 
>> install prefix.  And maybe you want to let them user their home directory be 
>> default if they've not specified it:
>> 
>> 
>> include(GNUInstallDirs)
>> 
>> if (CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
>> # NOTE: default to the home directory, assumes $HOME is defined in the 
>> environment
>> set(CMAKE_INSTALL_PREFIX $ENV{HOME} CACHE PATH "Installation prefix" 
>> FORCE) 
>> endif ()
>> 
>> [... usual stuff here ...]
>> 
>> # NOTE: relative path
>> install(TARGETS target_name DESTINATION "Library/Application 
>> Support/Adobe/Lightroom/Modules")
>> 
>> 
>> Then the user would just "make && make install" and it'll install to their 
>> ~/Library directory by default.
>> 
>> Then, if they have the permissions to do so, they can install to the global 
>> system location using:
>> 
>> cmake -D CMAKE_INSTALL_PREFIX=/ . &&
>> make &&
>> sudo make install
>> 
>> Mixing both in the same cmake invocation can be done, but now you've made it 
>> impossible to install into other locations (for testing, packaging, etc).
>> 
>> For example, someone might want to package it without sudo, so they might 
>> want to do this instead of "sudo make install":
>> 
>> make DESTDIR=$PWD/tmp install
>> 
>> and then you have a tmp/Library/ directory structure that can be made into a 
>> macOS .pkg installer:
>> 
>> pkgbuild --install-location / --identifier org.domain.pkgs.example 
>> --version 1.0.0 --root tmp example-1.0.0.pkg
>> 
>> And now you have a .pkg installer that updates the global /Library directory 
>> without needing to be root to build it.
>> 
>> 
>> Question -- is this a situation where you want a single build to install 
>> into both locations, or is the literally the same plugin and it only needs 
>> to be in one of the two locations (global vs. user)?  I interpreted your 
>> question to be about the latter, where the user really only needs one or the 
>> other, and it's the same plugin in both cases.
>> 
>> I don't know if cpack handles this for you, but hopefully this is helpful 
>> advice.
>> 
>> 
>>> On Thu, Oct 31, 2019 at 10:19 AM David Cole via cmake-developers 
>>>  wrote:
>>> According to the docs, the INSTALL command uses the absolute path if
>>> it is given as the DESTINATION, so  it should work.
>>> https://cmake.org/cmake/help/latest/command/install.html
>>> 
>>> Did you try using a double quoted string, instead of escaping the
>>> space with a backslash?
>>> 
>>> I think this should work for the absolute one:
>>> INSTALL( ... DESTINATION "/abs/path/to/some folder")
>>> 
>>> For the one in the home directory, I'm not sure if a string that
>>> starts with "~" is considered absolute or not, so it may or may not
>>> end up where you expect it. Can you resolve it before hand with a
>>> get_filename_component call, (or otherwise), and pass in a string that
>>> begins with "/" ...?
>>> 
>>> 
>>> Hope this helps,
>>> David C.
>>> 
>>> 
>>> On Mon, Oct 28, 2019 at 4:36 PM Roman Wüger  wrote:
>>> > Hello,
>>> > I tried to install a file/directory with productbuild on macOS which is 
>>> > generated with CPack
>>> > The most of the files are installed correctly, but I have two problems:
>>> >
>>> > If I want to install to “/Library/Application\ 
>>> > Support/Adobe/Lightroom/Modules”
>>> > If I want to install to the 

[CMake] CMake on host executing compiler inside docker

[Federico Kircheis]

Hello,

I'm trying to solve following problem.

test as many different compilers as possible with no (or minimal) 
maintenance burden.


As docker is the newest trend, I decided to give it a try (nearly using 
it for the first time).
Also the GCC team has official docker images 
(https://hub.docker.com/_/gcc/), so I decided to give it a try.


The main advantage is that I do not need to manage, compile and package 
myself all different compiler versions for my operating system.



The issue is that the integration between tools inside docker images and 
tools outside docker images is very bad.



I do not want to install CMake (and other tools) on those images as I 
could see on many projects because


  * it does not scale at all if I want to also test different version 
of CMake, make, ninja, clang, ...
  * It's a maintenance burden, as every time the base image gets 
updated, I need to update my modified images too
  * If I modify the official image, I need to know internal details 
that are not really relevant for testing the compiler (what OS, package 
manager, directory structure, ...)
  * It does not solve the integration issue, I do not think that 
installing the whole IDE would be a good idea.



At that point, compiling and packaging for the host platform is probably 
easier.



So what I tried was to take the docker images, and let my local CMake 
(CMake on the host, not in docker), use the compiler in the docker image.


This would have following advantages

  * compiler and build system are decoupled, I can easily test many 
version combinations of the two
  * No need to know how the image is build, I'm using it as a black 
box, as originally intended.
  * As most IDE understand make or CMake, I have the integration with 
the dockerized compiler for free (probably for other tools too)


I've created following toolchain file


set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_CROSSCOMPILING TRUE)

# FIXME: instead of hard coding 1000, map for real user id...
# Good enough for now as generated files are not owned by root
set(command 
"docker;run;--env;VERBOSE=1;-v;${CMAKE_SOURCE_DIR}:${CMAKE_SOURCE_DIR};-w;${CMAKE_SOURCE_DIR};--user;1000;gcc:5")


foreach(LANG C CXX ASM)
set(CMAKE_${LANG}_COMPILER_LAUNCHER ${command} CACHE STRING "")
endforeach()
#set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE "docker run --env 
VERBOSE=1 -v ${CMAKE_SOURCE_DIR}:${CMAKE_SOURCE_DIR} -w 
${CMAKE_SOURCE_DIR} --user 1000 gcc:5")



set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)


(the second attempt was setting `set_property(GLOBAL PROPERTY 
RULE_LAUNCH_COMPILE "docker run --env VERBOSE=1 -v 
${CMAKE_SOURCE_DIR}:${CMAKE_SOURCE_DIR} -w ${CMAKE_SOURCE_DIR} --user 
1000 gcc:5")`, but it did not make any difference)


and used it like



m -rf build;cmake -S . -B build 
-DCMAKE_TOOLCHAIN_FILE=toolchain-docker.cmake --debug-trycompile && 
cmake --build build



I can see that the makefiles all have "docker run " commands, which 
looks great, but CMake, in it's internal logic, does not seem to always 
apply the `RULE_LAUNCH_COMPILE` and `CMAKE_${LANG}_COMPILER_LAUNCHER`, 
as the output looks like:



-- The C compiler identification is GNU 9.2.1 



-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works


GCC 9.2.1 is the compiler on my local host, the output should have been 
version 5.


I've also noticed that internal tests, like 
/usr/share/cmake-3.13/Modules/CMakeTestCCompiler.cmake:52, gets executed 
with the "docker run" prefix, and they do not fail.



Is there some parameter that I'm missing, or is there a better way to 
achieve what I'm trying to do?


I can also verify that CMake does not always apply "RULE_LAUNCH_COMPILE" 
and "CMAKE_${LANG}_COMPILER_LAUNCHER", because if I add 
"set(CMAKE_C_COMPILER /usr/local/bin/gcc)" (which is the internal path 
in docker), then CMake prints



-- The C compiler identification is unknown
-- The ASM compiler identification is unknown
-- Didn't find assembler
CMake Error at CMakeLists.txt:12 (project):
  The CMAKE_C_COMPILER:

/usr/local/bin/gcc

  is not a full path to an existing compiler tool.

  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full 
path to

  the compiler, or to the compiler name if it is in the PATH.


as GCC on my host is "/usr/bin/gcc".
--

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at 

Re: [CMake] CMake link to external library

[Andrew Bell]

On Tue, Nov 12, 2019 at 7:39 AM .  wrote:

> Hi,
> I used instruction for CMake linking external library from
> https://stackoverflow.com/questions/8774593/cmake-link-to-external-library(for
> example)
> And it works on Ubuntu 16 only.
>
> When I try it made on Ubuntu 18 I got problem during start application:
> error while loading shared libraries: libfoo.so.3: cannot open shared
> object file: No such file or directory
>
> Could anybody help me in this problem?
>

https://unix.stackexchange.com/questions/22926/where-do-executables-look-for-shared-objects-at-runtime

-- 
Andrew Bell
andrew.bell...@gmail.com
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

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

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] CMake link to external library

[.]

Hi,
I used instruction for CMake linking external library from 
https://stackoverflow.com/questions/8774593/cmake-link-to-external-library(for 
example)
And it works on Ubuntu 16 only.

When I try it made on Ubuntu 18 I got problem during start application: 
error while loading shared libraries: libfoo.so.3: cannot open shared object 
file: No such file or directory

Could anybody help me in this problem?
Thanks, Serge.
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

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

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] CMake Error Flagged in MSVC Toolchain File

[Osman Zakir]

Yeah, I typed it correctly in the actual command and missed the C when 
copy-pasting it here.  Sorry about that.

I also want to know if it's possible to use LLVM 10 with the ClangCl toolset in 
VS2019.  The toolchain file itself uses LLVM 8.0.1, but I also have LLVM 10 
installed on my computer and I'd like to use that if possible.
-- 

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

[CMake] CMake Error Flagged in MSVC Toolchain File

[Osman Zakir]

I tried to configure a FLTK build with this:
"make .. -G "Visual Studio 16 2019" -A x64 -T "ClangCl" 
-DCMAKE_INSTALL_PREFIX=../install 
-DCMAKE_CXX_COMPILER=C:/llvm-project/install/bin/clang-cl.exe 
-DCMAKE_C_COMPILER=C:/llvm-project/install/bin/clang-cl.exe 
-DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-Xclang -pedantic -Xclang 
-std=c++17 -Xclang -Wall -Xclang -fexceptions"
"
and got an error saying:
"
CMake Error at C:/Program Files (x86)/Microsoft Visual 
Studio/2019/Community/MSBuild/Microsoft/VC/v160/Platforms/x64/PlatformToolsets/ClangCL/Toolset.targets:1:
  Parse error.  Expected a command name, got unquoted argument with text​
  

[CMake] CMake variable to set stack size

[Gautham B A via CMake]

Hi,

Is there a CMake variable to set the stack size of a target?
Upon searching the issues, I came across this one - 
https://gitlab.kitware.com/cmake/cmake/issues/17572 . It says that there is a 
CMake variable CMAKE_CXX_STACK_SIZE, but it isn’t clear whether 
CMAKE_CXX_STACK_SIZE can be used.
Further, the CMake documentation doesn’t seem to have anything on 
CMAKE_CXX_STACK_SIZE - 
https://cmake.org/cmake/help/v3.16/search.html?q=CMAKE_CXX_STACK_SIZE_keywords=yes=default

I’ve managed to set the stack size by setting the linker flag based on the 
compiler –
if (MSVC)
   set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /STACK:1000")
else ()
   set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,--stack,1000")
endif()

Having a CMake variable to set the stack size would greatly simplify things. 
Could anybody please give more info on this?

Thanks,
--Gautham
-- 

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

Re: [CMake] [cmake-developers] productbuild: Installing to absolute system path or to user home path

[David Cole via CMake]

According to the docs, the INSTALL command uses the absolute path if
it is given as the DESTINATION, so  it should work.
https://cmake.org/cmake/help/latest/command/install.html

Did you try using a double quoted string, instead of escaping the
space with a backslash?

I think this should work for the absolute one:
INSTALL( ... DESTINATION "/abs/path/to/some folder")

For the one in the home directory, I'm not sure if a string that
starts with "~" is considered absolute or not, so it may or may not
end up where you expect it. Can you resolve it before hand with a
get_filename_component call, (or otherwise), and pass in a string that
begins with "/" ...?


Hope this helps,
David C.


On Mon, Oct 28, 2019 at 4:36 PM Roman Wüger  wrote:
>
> 
>
> Hello,
>
>
>
> I tried to install a file/directory with productbuild on macOS which is 
> generated with CPack
>
> The most of the files are installed correctly, but I have two problems:
>
>
>
> If I want to install to “/Library/Application\ 
> Support/Adobe/Lightroom/Modules”
> If I want to install to the users modules folder “~/Library/Application\ 
> Support/Adobe/Lightroom/Modules”
>
>
>
> How can I archive these two?
>
>
>
> I already tried the following with no luck:
>
> install(DIRECTORY 
> $/${CMAKE_PROJECT_NAME}.lrplugin
>
> DESTINATION /Library/Application\ 
> Support/Adobe/Lightroom/Modules)
>
>
>
> install(DIRECTORY 
> $/${CMAKE_PROJECT_NAME}.lrplugin
>
> DESTINATION ~/Library/Application\ 
> Support/Adobe/Lightroom/Modules)
>
>
>
> Best Regards
>
> Roman
>
> --
>
> 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-developers
-- 

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

Re: [CMake] CMake link order

[Juan Sanchez]

Hello,

I have always used all of the libraries at once to the
TARGET_LINK_LIBRARIES command.

In the following example, the link line order appears the same as the
libraries are listed on the line.

TARGET_LINK_LIBRARIES(devsim_tcl ${LIBRARIES} ${TCL_ARCHIVE}
${SUPERLU_ARCHIVE} ${BLAS_ARCHIVE} ${SQLITE3_ARCHIVE}
${SYMDIFF_ARCHIVE} ${OPTIONAL_LIBS} ${PTHREAD_LIB} ${DLOPEN_LIB})

This is important because my LIBRARIES need to all be on the link line
before the other libraries I am using.

Another option is to explicitly us ADD_DEPENDENCY to add dependencies
between the libraries:
https://cmake.org/cmake/help/latest/command/add_dependencies.html

If I had multiple libraries hopelessly intertwined, I would list them
multiple times:
A B A C

or force the linker to do multiple passes:

 -Wl,--start-group A B C  -Wl,--end-group

This is by using the start-group and end-group flags in your
TARGET_LINK_LIBRARIES line.
https://cmake.org/pipermail/cmake/2011-May/044478.html

Regards,

Juan






On Fri, Oct 18, 2019 at 9:56 AM Bon, William 
wrote:

> Hello,
>
> we are facing an issue while using cmake and we have no idea how to solve
> or debug it.
> We have a complex and huge project (about 50 subdirectories and
> dependencies everywhere), and we are facing issue regarding the link order.
> There is a lot of dependencies between those projects, and to summarize,
> we have two libraries A and B
> A is an imported library from headers and shared lib .so declared like this
> ```
> add_library(A SHARED IMPORTED GLOBAL)
> set_target_properties(A PROPERTIES
> IMPORTED_LINK_INTERFACE_LANGUAGES "C"
> IMPORTED_LOCATION ${A_LIBRARY})
> ```
>
> B is a system library part of a package.
>
> We need to link A before B in every case.
>
> In every project, we include A before B using
> ```
> find_package(B)
> target_link_libraries(${library_produced} PUBLIC A)
> target_link_libraries(${library_produced} PUBLIC B)
> ```
>
> but from time to time, we don't know why, the library produced link in the
> wrong order (checked with ldd and make VERBOSE=1).
> it links B before A.
>
> Is there a way to find out what happens and why cmake change the link
> order for some project and not all projects ?
>
> Best regards,
>
> Bill
> --
>
> 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

Re: [CMake] CMake link order

[Andreas Naumann]

Hey all,

I face a similar problem when constructing a correct (and predictable)
link order for Linux and Cygwin. It would be of great help, if there is
some documentation.

In particular, I would raise two question
    1) when does the link order change?
    2) when does a clean up happen and in which way?

I did also some experiments on linux with cmake 3.13.4 and ended up with
the appended (nearly) minimal example. The example consists of:

 * two "fake"-libraries A and B, whose paths are stored in two
   variables libA and libB respectively. (they serve just for
   demonstration, no real linking is required)
 * two interface libraries interfaceA and interfaceB. Each links to the
   corresponding fake library.
 * two imported libraries impA and impB, each has the location to the
   corresponding fake library.

Now I construct some combinations:

1. An interface library interfaceA_B_vA, which links against the
   interface libraries "interfaceA interfaceB ${libA}" and an
   executable, which links only against interfaceA_B_vA. For that
   executable, I get the link order "B A"
2. Suppose one tries to correct that and link explicitly against with
   the variable. Such an executable which links as "${libA}
   interfaceA_B_vA". In that case, I got the link order "A A B". So we
   have a changed order compared to the previous experiment.
3. If I use the imported libraries instead of the variables from
   experiment 1, I get the link order A B A, as expected.

From these experiments, I got the impression, that

1. linking through variables remains a nightmare. That is nothing new.
2. interface libraries might change their order
3. imported libraries lead to a more stable link order?

I hope somebody could shed some light in this behavior.

Best regards,
Andreas


Am 18.10.19 um 18:24 schrieb Fred Baksik:



On Fri, Oct 18, 2019, at 11:55 AM, Fred Baksik wrote:


In target_link_libraries it states that "The library dependency graph
is normally acyclic (a DAG)".  I recall from my own experience that
the DAG is not always created the same way when generating the
project.  It has to do with the way with this part of CMake is
implemented (C++ containers and that sort of thing) so while all the
inputs are the same the order is Not the same so it produces a
different DAG which changed the ordering of the components build
order which also altered the link order.

For the GHS Generator to ensure that the exact same project files are
output we sorted the components by name into a vector first (instead
of just using a set) before supplying it to this algorithm.  Then the
results were always the same.



Sorry, I wanted to clarify this a bit.  The DAG is correct. For
example lets say A depends on B and C and then C on D.  This DAG
always comes out the same.  But when you try to extract the dependents
of A it sometimes returns something that will give you B then C or C
then B when accessing them in a linear order. So there were
differences if you inspected these items with the debugger.

When I ran across these kinds of things with the GHS Generator we sort
things in lexicographical order to produce the same results every time.

Best regards,
Fred



project(testLinkOrder)
cmake_minimum_required(VERSION 3.5)

file(WRITE "simpleProg.cc" "int main() { return 0; }")
set(libA "${CMAKE_BINARY_DIR}/A.a")
file(WRITE "${libA}" "i am not a library")

set(libB "${CMAKE_BINARY_DIR}/B.a")
file(WRITE "${libB}" "i am not a library")

add_library(impA IMPORTED STATIC)
set_target_properties(impA PROPERTIES IMPORTED_LOCATION ${libA})

add_library(impB IMPORTED STATIC)
set_target_properties(impB PROPERTIES IMPORTED_LOCATION ${libB})

add_library(interfaceA INTERFACE)
target_link_libraries(interfaceA INTERFACE ${libA})

add_library(interfaceB INTERFACE)
target_link_libraries(interfaceB INTERFACE ${libB})
#target_link_libraries(interfaceA INTERFACE ${libB})

add_library(interface_A_B_vA INTERFACE)
target_link_libraries(interface_A_B_vA INTERFACE interfaceA interfaceB ${libA})

add_executable(linkInterface_A_B_vA simpleProg.cc)
target_link_libraries(linkInterface_A_B_vA interface_A_B_vA)

add_executable(linkvA_IABAVA simpleProg.cc)
target_link_libraries(linkvA_IABAVA ${libA} interface_A_B_vA)

add_library(interface_impA_impB_vA INTERFACE)
target_link_libraries(interface_impA_impB_vA INTERFACE impA impB ${libA})

add_executable(linkInterface_impA_impB_vA simpleProg.cc)
target_link_libraries(linkInterface_impA_impB_vA interface_impA_impB_vA)
-- 

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 

Re: [CMake] CMake link order

[Fred Baksik]

On Fri, Oct 18, 2019, at 11:55 AM, Fred Baksik wrote:
> 
> In target_link_libraries it states that "The library dependency graph is 
> normally acyclic (a DAG)". I recall from my own experience that the DAG is 
> not always created the same way when generating the project. It has to do 
> with the way with this part of CMake is implemented (C++ containers and that 
> sort of thing) so while all the inputs are the same the order is Not the same 
> so it produces a different DAG which changed the ordering of the components 
> build order which also altered the link order.
> 
> For the GHS Generator to ensure that the exact same project files are output 
> we sorted the components by name into a vector first (instead of just using a 
> set) before supplying it to this algorithm. Then the results were always the 
> same.
> 

Sorry, I wanted to clarify this a bit. The DAG is correct. For example lets say 
A depends on B and C and then C on D. This DAG always comes out the same. But 
when you try to extract the dependents of A it sometimes returns something that 
will give you B then C or C then B when accessing them in a linear order. So 
there were differences if you inspected these items with the debugger.

When I ran across these kinds of things with the GHS Generator we sort things 
in lexicographical order to produce the same results every time.

Best regards,
Fred-- 

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

Re: [CMake] CMake link order

[Fred Baksik]

On Fri, Oct 18, 2019, at 6:24 AM, Bon, William wrote:
> Hello,
> 
> we are facing an issue while using cmake and we have no idea how to solve or 
> debug it.
> We have a complex and huge project (about 50 subdirectories and dependencies 
> everywhere), and we are facing issue regarding the link order.
> There is a lot of dependencies between those projects, and to summarize, we 
> have two libraries A and B
> A is an imported library from headers and shared lib .so declared like this
> ```
> add_library(A SHARED IMPORTED GLOBAL)
> set_target_properties(A PROPERTIES
>  IMPORTED_LINK_INTERFACE_LANGUAGES "C"
>  IMPORTED_LOCATION ${A_LIBRARY})
> ```
> 
> B is a system library part of a package.
> 
> We need to link A before B in every case.
> 
> In every project, we include A before B using
> ```
> find_package(B)
> target_link_libraries(${library_produced} PUBLIC A)
> target_link_libraries(${library_produced} PUBLIC B)
> ```
> 
> but from time to time, we don't know why, the library produced link in the 
> wrong order (checked with ldd and make VERBOSE=1).
> it links B before A.
> 
> Is there a way to find out what happens and why cmake change the link order 
> for some project and not all projects ?
> 
> Best regards,
> 
> Bill
> 

I'm going by memory when I saw something similar when updating the GHS 
Generator in CMake.

In target_link_libraries it states that "The library dependency graph is 
normally acyclic (a DAG)". I recall from my own experience that the DAG is not 
always created the same way when generating the project. It has to do with the 
way with this part of CMake is implemented (C++ containers and that sort of 
thing) so while all the inputs are the same the order is Not the same so it 
produces a different DAG which changed the ordering of the components build 
order which also altered the link order.

For the GHS Generator to ensure that the exact same project files are output we 
sorted the components by name into a vector first (instead of just using a set) 
before supplying it to this algorithm. Then the results were always the same.

But if I remember correctly an "add_dependency( B A )" or otherwise make B 
dependent on A does forces a dependency between the two libraries which forces 
the DAG to always put A before B.

I would bet that if you just did the project generation over and over again 
into different build directories you'll notice these kinds of differences in 
the different Makefiles (or whatever output that is expected by the generator).

This is how I noticed the issue with the GHS Generator because the ordering of 
some items were just changing in an unexpected fashion and I was always 
comparing what it generated against what I was expecting it to generate.

I never asked the main developers about this; and again this is just my own 
observations.

Best regards,
Fred-- 

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

[CMake] CMake link order

[Bon, William]

Hello,

we are facing an issue while using cmake and we have no idea how to solve or 
debug it.
We have a complex and huge project (about 50 subdirectories and dependencies 
everywhere), and we are facing issue regarding the link order.
There is a lot of dependencies between those projects, and to summarize, we 
have two libraries A and B
A is an imported library from headers and shared lib .so declared like this
```
add_library(A SHARED IMPORTED GLOBAL)
set_target_properties(A PROPERTIES
IMPORTED_LINK_INTERFACE_LANGUAGES "C"
IMPORTED_LOCATION ${A_LIBRARY})
```

B is a system library part of a package.

We need to link A before B in every case.

In every project, we include A before B using
```
find_package(B)
target_link_libraries(${library_produced} PUBLIC A)
target_link_libraries(${library_produced} PUBLIC B)
```

but from time to time, we don't know why, the library produced link in the 
wrong order (checked with ldd and make VERBOSE=1).
it links B before A.

Is there a way to find out what happens and why cmake change the link order for 
some project and not all projects ?

Best regards,

Bill
-- 

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

Re: [CMake] CMake 3.15 fails to install on OS X

[Eric Doenges]

System Integrity Protection (SIP, introduced with macOS 10.11) prevents 
you from writing into various system directories (like /usr) even as the 
root user. You can either install cmake to a different location (like 
/usr/local, which apparently is not protected), or disable SIP entirely 
(which is not recommended). See this Wikipedia article 
<https://en.wikipedia.org/wiki/System_Integrity_Protection> for more 
information on SIP.


Am 15.10.19 um 07:05 schrieb Jeffrey Walton:

I'm building CMake cmake-3.15.4.tar.gz on OS X 10.12. The machine is
stripped down, and only has the COmmand Line tools. No Xcode and
friends.

I configured with:

 ./configure --prefix=/usr

Configure appears OK. Make appears OK. Install is failing:

 $ sudo make install VERBOSE=1
 ...
[100%] Built target foo
/Users/jwalton/cmake-3.15.4/Bootstrap.cmk/cmake -E
cmake_progress_start /Users/jwalton/cmake-3.15.4/CMakeFiles 0
/Library/Developer/CommandLineTools/usr/bin/make -f
CMakeFiles/Makefile2 preinstall
make[1]: Nothing to be done for `preinstall'.
Install the project...
bin/cmake -P cmake_install.cmake
-- Install configuration: ""
CMake Error at Source/kwsys/cmake_install.cmake:36 (file):
   file cannot create directory: /usr/doc/cmake-3.15/cmsys.  Maybe need
   administrative privileges.
Call Stack (most recent call first):
   cmake_install.cmake:37 (include)

make: *** [install] Error 1

--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com <mailto:musterm...@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

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

[CMake] CMake 3.15 fails to install on OS X

[Jeffrey Walton]

I'm building CMake cmake-3.15.4.tar.gz on OS X 10.12. The machine is
stripped down, and only has the COmmand Line tools. No Xcode and
friends.

I configured with:

./configure --prefix=/usr

Configure appears OK. Make appears OK. Install is failing:

$ sudo make install VERBOSE=1
...
[100%] Built target foo
/Users/jwalton/cmake-3.15.4/Bootstrap.cmk/cmake -E
cmake_progress_start /Users/jwalton/cmake-3.15.4/CMakeFiles 0
/Library/Developer/CommandLineTools/usr/bin/make -f
CMakeFiles/Makefile2 preinstall
make[1]: Nothing to be done for `preinstall'.
Install the project...
bin/cmake -P cmake_install.cmake
-- Install configuration: ""
CMake Error at Source/kwsys/cmake_install.cmake:36 (file):
  file cannot create directory: /usr/doc/cmake-3.15/cmsys.  Maybe need
  administrative privileges.
Call Stack (most recent call first):
  cmake_install.cmake:37 (include)

make: *** [install] Error 1
-- 

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

Re: [CMake] cmake end user vs. developer rpath handling

[DIXON, MARK C.]

On Thu, 10 Oct 2019, Eric Noulard wrote:
...
> with patchelf is works with an intriguing warning:
> warning: working around a Linux kernel bug by creating a hole of 2093056
> bytes in ‘/path/to/executable’
>
> which seems to be a resolved issue:
> https://github.com/NixOS/patchelf/issues/92
>
> after that on the modified executable,
> chrpath is printing weird output when asking to read rpath.
> patchelf does properly print modified rpath.
>
> I think the SO article gives enough reference for this:
> https://stackoverflow.com/questions/13769141/can-i-change-rpath-in-an-already-compiled-binary
>
> So I was wrong, thank you for your honest question Jakub.
> I learned something usefull thanks to you.
...

Thanks both! Great news - being unable to grow rpath was always really 
irritating.

Mark
-- 

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

Re: [CMake] cmake end user vs. developer rpath handling

[DIXON, MARK C.]

On Thu, 10 Oct 2019, Eric Noulard wrote:
...
> No rpath and using "only" LD_LIBRARY_PATH is not feasible in that case?
> Removing rpath is easy; chrpath -d lib_or_exe

You could but, to avoid a maintenance headache, you'd normally end up 
getting the environment module to load any prereq environment modules, 
which would modify LD_LIBRARY_PATH.

In either case, it'd mean unexpectedly polluting the user's environment 
with things they didn't explicitly ask for, which I don't like doing.

...
> Or may be  commenting it out and specify CMAKE_INSTALL_RPATH on the command
> line:
>
> cmake
> -DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath
> 
...

Sorry - yes, I'm commenting it out and then specifying the 
CMAKE_INSTALL_RPATH I want on the command line.

Best,

Mark
-- 

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

Re: [CMake] cmake end user vs. developer rpath handling

[Zakrzewski, Jakub]

From: Eric Noulard 
Sent: 10 October 2019 14:43
To: Zakrzewski, Jakub
Cc: cmake@cmake.org
Subject: Re: [CMake] cmake end user vs. developer rpath handling


> So I was wrong, thank you for your honest question Jakub.
> I learned something usefull thanks to you.


?No problem, thanks for trying out.
I'd like to think that asking and answering questions (even the seemingly 
stupid ones) makes us learn new things.

--
Have a nice one,
Jakub
-- 

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

Re: [CMake] cmake end user vs. developer rpath handling

[Eric Noulard]

Le jeu. 10 oct. 2019 à 14:30, Eric Noulard  a
écrit :

>
>
> Le jeu. 10 oct. 2019 à 14:02, Zakrzewski, Jakub <
> jakub.zakrzew...@scheer-group.com> a écrit :
>
>> --
>> *From:* CMake  on behalf of Eric Noulard <
>> eric.noul...@gmail.com>
>> *Sent:* 10 October 2019 12:05
>> *To:* DIXON, MARK C.
>> *Cc:* cmake@cmake.org
>> *Subject:* [DKIM] Re: [CMake] cmake end user vs. developer rpath handling
>>
>>
>> > No they can't because the maximum size is burried into the binary ELF
>> file,
>> > that why CMake "reserve" some space with many "" in order to replace
>> BUILD_RPATH with INSTALL_RPATH when doing
>> > 'install'.
>>
>> Interesting.
>> So you're saying that this:
>> https://github.com/NixOS/patchelf/blob/8cc2d6b0946abb0009058865cd46165b69c4/src/patchelf.cc#L1288-L1319
>> does not really work? (An honest question)
>>
>
> Nope I meant that my manual page forr chrpath says:
>-r  | --replace 
>   Replace current rpath or runpath setting with the path
> given.  The new path must be shorter or the same length as the current path.
>
> patchelf does not seem to have this limitation.
> I remember trying and being hit by that issue, but I did not tried it
> recently.
> I'll try again and come back to you.
>

with chrpath try to replace an rpath with a longer one I get:
new rpath '/../lib:/purposely/too/long/rpath/hdsjds/dshkjhdsk/dsgdjsj' too
large; maximum length 104

with patchelf is works with an intriguing warning:
warning: working around a Linux kernel bug by creating a hole of 2093056
bytes in ‘/path/to/executable’

which seems to be a resolved issue:
https://github.com/NixOS/patchelf/issues/92

after that on the modified executable,
chrpath is printing weird output when asking to read rpath.
patchelf does properly print modified rpath.

I think the SO article gives enough reference for this:
https://stackoverflow.com/questions/13769141/can-i-change-rpath-in-an-already-compiled-binary

So I was wrong, thank you for your honest question Jakub.
I learned something usefull thanks to you.


-- 
Eric
-- 

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

Re: [CMake] cmake end user vs. developer rpath handling

[Eric Noulard]

Le jeu. 10 oct. 2019 à 14:02, Zakrzewski, Jakub <
jakub.zakrzew...@scheer-group.com> a écrit :

> --
> *From:* CMake  on behalf of Eric Noulard <
> eric.noul...@gmail.com>
> *Sent:* 10 October 2019 12:05
> *To:* DIXON, MARK C.
> *Cc:* cmake@cmake.org
> *Subject:* [DKIM] Re: [CMake] cmake end user vs. developer rpath handling
>
>
> > No they can't because the maximum size is burried into the binary ELF
> file,
> > that why CMake "reserve" some space with many "" in order to replace
> BUILD_RPATH with INSTALL_RPATH when doing
> > 'install'.
>
> Interesting.
> So you're saying that this:
> https://github.com/NixOS/patchelf/blob/8cc2d6b0946abb0009058865cd46165b69c4/src/patchelf.cc#L1288-L1319
> does not really work? (An honest question)
>

Nope I meant that my manual page forr chrpath says:
   -r  | --replace 
  Replace current rpath or runpath setting with the path
given.  The new path must be shorter or the same length as the current path.

patchelf does not seem to have this limitation.
I remember trying and being hit by that issue, but I did not tried it
recently.
I'll try again and come back to you.

-- 
Eric
-- 

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

Re: [CMake] cmake end user vs. developer rpath handling

[Zakrzewski, Jakub]

From: CMake  on behalf of Eric Noulard 

Sent: 10 October 2019 12:05
To: DIXON, MARK C.
Cc: cmake@cmake.org
Subject: [DKIM] Re: [CMake] cm?ake end user vs. developer rpath handling


> No they can't because the maximum size is burried into the binary ELF file,
> that why CMake "reserve" some space with many ";;;" in order to replace 
> BUILD_RPATH with INSTALL_RPATH when doing
> 'install'.

Interesting.
So you're saying that this: 
https://github.com/NixOS/patchelf/blob/8cc2d6b0946abb0009058865cd46165b69c4/src/patchelf.cc#L1288-L1319?
does not really work? (An honest question)

-- 

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

Re: [CMake] cmake end user vs. developer rpath handling

[Eric Noulard]

Le jeu. 10 oct. 2019 à 13:08, DIXON, MARK C.  a
écrit :

> On Thu, 10 Oct 2019, Eric Noulard wrote:
> ...
> > No they can't because the maximum size is burried into the binary ELF
> file,
> > that why CMake "reserve" some space with many ";;;" in order to replace
> > BUILD_RPATH with INSTALL_RPATH when doing
> > 'install'.
>
> Hi Eric,
>
> Interesting - any ideas on how big the padding is?
>


Not sure, but I bet CMake is reserving as much space as needed for the
forthcoming INSTALL_RPATH
(as opposed to BUILD_RPATH) he knows when specified in the CMakeLists.txt
I you rebuild the concerned from source try configuring it with a stupidly
long CMAKE_INSTALL_RPATH
i.e.

cmake
-DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath


Then, you can surely have a look using  chrpath -l lib_or_exe.


> > Note however that you should be able to "delete" RPATH: chrpath -d
> > and then rely on LD_LIBRARY_PATH, ld.so.config, etc
> >
> > The thing I don't quite understand why you need to replace/amend RPATH.
> In
> > my (very personal) use case when I have to integrate third-party
> software:
>
> My use case is where:
>
> - I install some software, made available to others via environment
>modules (http://modules.sourceforge.net/).
>
> - The installed software is dynamically linked to other libraries, also
>installed via environment modules.
>
> - I don't want to make people load modules for prerequisite libraries
>(and prerequisites for the prerequisites...) to use the software.
>


ok I see, I did use modules a long time ago on some now oldish supercomputer
in order to play with various compilers of library versions.


>
> A complication is that I end up having to build lots of copies of the same
> software but built with different prerequisites... so it has to be
> automated on top of the upstream project's build system.
>
> For applications using libraries, I've tended to use wrapper scripts as it
> means fewer arguments with build systems. But for libraries using
> libraries, rpath's the only real option.
>

No rpath and using "only" LD_LIBRARY_PATH is not feasible in that case?
Removing rpath is easy; chrpath -d lib_or_exe


> My rpath can get quite long.
>

Yes now I see why, depending on the number of  prerequisite you have and
how many
modules are loaded.


> ...
> > If the developers of the software you are using have chosen in their
> CMake
> > build-system to define an install RPATH your only safe bet
> > is probably to build & install the software at your favorite location or
> > propose an upstream patch for supporting unspecified RPATH.
> >
> > But may be I miss something in your use case?
>
> I guess I should be proposing upstream patches but, there are so many
> software projects to do this for, it has always been simpler to carry
> forward a small patch or patches. Perhaps I should be a better citizen.
>

It may not be tractable to file dozen of upstream patch and wait for
feedback
but in the case the build system does not offer a way to chose install
rpath content I think you are stucked
(beside remove rpath).


In this case, what feels easiest is to keep a patch commenting out the
> developer's RPATH definition in CMakeLists.txt, identified by Jakub
> earlier.
>

Yes I agree. However I my hypothesis of space reservation in RPATH by cmake
is write
you may want to replace with something that fits your needs and not simply
commenting it out.
Or may be  commenting it out and specify CMAKE_INSTALL_RPATH on the command
line:

cmake
-DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath

https://cmake.org/cmake/help/v3.15/variable/CMAKE_INSTALL_RPATH.html

-- 
Eric
-- 

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

Re: [CMake] cmake end user vs. developer rpath handling

[DIXON, MARK C.]

On Thu, 10 Oct 2019, Eric Noulard wrote:
...
> No they can't because the maximum size is burried into the binary ELF file,
> that why CMake "reserve" some space with many ";;;" in order to replace
> BUILD_RPATH with INSTALL_RPATH when doing
> 'install'.

Hi Eric,

Interesting - any ideas on how big the padding is?


> Note however that you should be able to "delete" RPATH: chrpath -d
> and then rely on LD_LIBRARY_PATH, ld.so.config, etc
>
> The thing I don't quite understand why you need to replace/amend RPATH. In
> my (very personal) use case when I have to integrate third-party software:

My use case is where:

- I install some software, made available to others via environment
   modules (http://modules.sourceforge.net/).

- The installed software is dynamically linked to other libraries, also
   installed via environment modules.

- I don't want to make people load modules for prerequisite libraries
   (and prerequisites for the prerequisites...) to use the software.

A complication is that I end up having to build lots of copies of the same 
software but built with different prerequisites... so it has to be 
automated on top of the upstream project's build system.

For applications using libraries, I've tended to use wrapper scripts as it 
means fewer arguments with build systems. But for libraries using 
libraries, rpath's the only real option.

My rpath can get quite long.


...
> If the developers of the software you are using have chosen in their CMake
> build-system to define an install RPATH your only safe bet
> is probably to build & install the software at your favorite location or
> propose an upstream patch for supporting unspecified RPATH.
>
> But may be I miss something in your use case?

I guess I should be proposing upstream patches but, there are so many 
software projects to do this for, it has always been simpler to carry 
forward a small patch or patches. Perhaps I should be a better citizen.

In this case, what feels easiest is to keep a patch commenting out the 
developer's RPATH definition in CMakeLists.txt, identified by Jakub 
earlier.

Cheers,

Mark
-- 

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

Re: [CMake] cmake end user vs. developer rpath handling

[Eric Noulard]

Le jeu. 10 oct. 2019 à 10:36, DIXON, MARK C.  a
écrit :

> On Wed, 9 Oct 2019, Aaron Cohen wrote:
>
> > Is it not feasible to just let the build system do whatever it is going
> to
> > and use "chrpath" or "patchelf" to change the rpath after-the-fact?
>
> Thanks for the suggestion, but I need to add directories to the rpath: I
> believe that neither utility allows it to increase in size.
>


No they can't because the maximum size is burried into the binary ELF file,
that why CMake "reserve" some space with many ";;;" in order to replace
BUILD_RPATH with INSTALL_RPATH when doing
'install'.

Note however that you should be able to "delete" RPATH: chrpath -d
and then rely on LD_LIBRARY_PATH, ld.so.config, etc

The thing I don't quite understand why you need to replace/amend RPATH. In
my (very personal) use case when I have to integrate third-party software:

1a) I compile them from source and install them using the install prefix *I
need*. For cmake enabled build
 the RPATH will be updated with the one I need *during install*

2a) I use relocatable binary package (of any kind rpm, deb, or even tar.gz)
for which I know that RPATH are
  relative which can adapt to the location where I put them.
  If I cannot find a relocatable binary package then I go back to 1a).

As noted by Hendrik not every software developer are aware of the need for
relocation so they may bury non-relocatable rpath in their buildsystem.

Note that there is usually 2 options for CMake buildsystem and install
RPATH.
You can either:
 1. set some install RPATH (preferably in a relocatable way using $ORIGIN)
 2. don't specify install RPATH at all and let the final user/integrator
setup LD_LIBRARY_PATH or ld.so.config etc...

This is quite well summarized here:
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling

If the developers of the software you are using have chosen in their CMake
build-system to define an install RPATH your only safe bet
is probably to build & install the software at your favorite location or
propose an upstream patch for supporting unspecified RPATH.

But may be I miss something in your use case?

-- 
Eric
-- 

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

Re: [CMake] cmake end user vs. developer rpath handling

[DIXON, MARK C.]

On Wed, 9 Oct 2019, Aaron Cohen wrote:

> Is it not feasible to just let the build system do whatever it is going to
> and use "chrpath" or "patchelf" to change the rpath after-the-fact?

Thanks for the suggestion, but I need to add directories to the rpath: I 
believe that neither utility allows it to increase in size.

:)

Mark
-- 

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

Re: [CMake] cmake end user vs. developer rpath handling

[Hendrik Sattler]

Am 9. Oktober 2019 08:09:19 MESZ schrieb "Zakrzewski, Jakub" 
>That "something" seems to be line 257:
>set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}")

IMHO setting this to something based on CMAKE_INSTALL_PREFIX is rarely a good 
idea if it can be relative to the runtime path of the executable. The above 
makes the program not relocatable even though that's easily possible on many 
systems.

HS

-- 

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

Re: [CMake] cmake end user vs. developer rpath handling

[Aaron Cohen]

Is it not feasible to just let the build system do whatever it is going to
and use "chrpath" or "patchelf" to change the rpath after-the-fact?

On Wed, Oct 9, 2019 at 11:48 AM DIXON, MARK C. 
wrote:

> On Wed, 9 Oct 2019, Craig Scott wrote:
> ...
> >>> Is there a way to reliably add to, or at least override, the
> developer's
> >>> rpath in any cmake-built software?
> >>
> >> Short of editing the build system scripts? I doubt...
> >
> > The CMAKE_INSTALL_RPATH variable is used to initialise the INSTALL_RPATH
> > property of a target when that target is created. If you are pulling in
> > these other projects via add_subdirectory() rather than building them
> > standalone, you could modify the INSTALL_RPATH property of the targets
> you
> > want to change from within your own top level project after
> > add_subdirectory() returns.
> ...
>
> Thanks for this. My knowledge of cmake is pretty poor - I assume it uses
> the same definition of target as make. So you're saying I'd need to know
> the project's interesting targets first.
>
> My choices are: maintain a patch to the software's build system files or
> maintain a patch to encaspulate the software's build system files and
> drive with a config file. Right?
>
> Thanks,
>
> Mark
> --
>
> 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

Re: [CMake] cmake end user vs. developer rpath handling

[DIXON, MARK C.]

On Wed, 9 Oct 2019, Craig Scott wrote:
...
>>> Is there a way to reliably add to, or at least override, the developer's
>>> rpath in any cmake-built software?
>>
>> Short of editing the build system scripts? I doubt...
>
> The CMAKE_INSTALL_RPATH variable is used to initialise the INSTALL_RPATH
> property of a target when that target is created. If you are pulling in
> these other projects via add_subdirectory() rather than building them
> standalone, you could modify the INSTALL_RPATH property of the targets you
> want to change from within your own top level project after
> add_subdirectory() returns.
...

Thanks for this. My knowledge of cmake is pretty poor - I assume it uses 
the same definition of target as make. So you're saying I'd need to know 
the project's interesting targets first.

My choices are: maintain a patch to the software's build system files or 
maintain a patch to encaspulate the software's build system files and 
drive with a config file. Right?

Thanks,

Mark
-- 

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

Re: [CMake] cmake end user vs. developer rpath handling

[DIXON, MARK C.]

On Wed, 9 Oct 2019, Zakrzewski, Jakub wrote:
...
> That "something" seems to be line 257: set(CMAKE_INSTALL_RPATH 
> "${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}")

There's a second something that's adding boost's library directory. I'm 
guessing this is maybe coming from my copy of cmake's boost detection 
code.

>> Is there a way to reliably add to, or at least override, the developer's
>> rpath in any cmake-built software?
>
> Short of editing the build system scripts? I doubt...

Drat. It would be a very useful feature to have: I install a lot of 
software for other people to use, and maintaining my own patches is a big 
headache.

Big minus in the "comparison with GNU configure" column... setting 
LD_RUN_PATH normally does the trick there.

Thanks,

Mark
-- 

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

Re: [CMake] CMake and Ninja, RERUN_CMAKE useless?

[Robert Maynard via CMake]

The default generator and all other associated information ( '-D' ) is
kept in the CMakeCache.txt file in the root of the build directory.
The execution of `cmake -S  -B ` will reload
this cache before doing anything else. Have you verified that your
build directory hasn't deleted this file?

On Tue, Oct 8, 2019 at 8:31 PM Nagurne, James via CMake  wrote:
>
> Hi all,
>
>
>
> My question comes from a Ninja generator build system, and is specifically 
> about an internal rule generated by cmake.
>
> What is the purpose of the RERUN_CMAKE rule generated by CMake with a Ninja 
> generator?
>
>
>
> In the current repo, the only reference to this rule is in 
> WriteTargetRebuildManifest here
>
> At line 1285, the rule is written out, seemingly as-is.
>
>
>
> According to lines 1274 to 1284, the only actual behavior of this command, 
> which is executed whenever the source CMakeLists.txt file, files included 
> from the CMakeLists, and some other CMake installation files change, is:
>
> cmake -S  -B 
>
>
>
> This seems completely insufficient for “re-running” cmake. The most obvious 
> flaw is the absence of the generator. When I’ve seen this rule fire, my Ninja 
> build system adds a useless Makefile to the build system, and then 
> (hopefully) continues building as if nothing had been done at all, without so 
> much as inspecting that Makefile.
>
>
>
> What about command-line arguments like -D?
>
>
>
> Am I missing the purpose of this rule or potentially doing something 
> non-standard? The reason I send an email is because this behavior is sending 
> my project into a cmake loop where it detects build.ninja is out of date, 
> re-runs cmake to generate a Makefile instead of a ninja build system, and 
> then infinitely repeats because it never actually re-ran anything.
>
>
>
> Thanks,
>
> JB
>
> Code Generation
>
> Texas Instruments
>
> --
>
> 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

Re: [CMake] cmake end user vs. developer rpath handling

[Craig Scott]

On Wed, Oct 9, 2019 at 5:24 PM Zakrzewski, Jakub <
jakub.zakrzew...@scheer-group.com> wrote:

>
> 
> From: CMake  on behalf of DIXON, MARK C. <
> mark.c.di...@durham.ac.uk>
> Sent: 08 October 2019 17:25
> To: cmake@cmake.org
> Subject: [CMake] cmake end user vs. developer rpath handling
>
> >Sometimes, this does the trick. When it does, I'm very happy:
> >
> >   cmake -D CMAKE_INSTALL_RPATH="/my/rpath" source_dir
> >
> >I'm currently looking at a package
> >(https://github.com/PointCloudLibrary/pcl) where this has no bearing on
> >the rpath of the installed software - I seem to get something set by the
> >developer.
>
> That "something" seems to be line 257:
> set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}")
>
> >Is there a way to reliably add to, or at least override, the developer's
> >rpath in any cmake-built software?
>
>
> Short of editing the build system scripts? I doubt...
>

The CMAKE_INSTALL_RPATH variable is used to initialise the INSTALL_RPATH
property of a target when that target is created. If you are pulling in
these other projects via add_subdirectory() rather than building them
standalone, you could modify the INSTALL_RPATH property of the targets you
want to change from within your own top level project after
add_subdirectory() returns.

-- 
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
-- 

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

Re: [CMake] cmake end user vs. developer rpath handling

[Zakrzewski, Jakub]

From: CMake  on behalf of DIXON, MARK C. 

Sent: 08 October 2019 17:25
To: cmake@cmake.org
Subject: [CMake] cmake end user vs. developer rpath handling

>Sometimes, this does the trick. When it does, I'm very happy:
>
>   cmake -D CMAKE_INSTALL_RPATH="/my/rpath" source_dir
>
>I'm currently looking at a package
>(https://github.com/PointCloudLibrary/pcl) where this has no bearing on
>the rpath of the installed software - I seem to get something set by the
>developer.

That "something" seems to be line 257:
set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}")

>Is there a way to reliably add to, or at least override, the developer's
>rpath in any cmake-built software?


Short of editing the build system scripts? I doubt...
-- 

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

[CMake] CMake and Ninja, RERUN_CMAKE useless?

[Nagurne, James via CMake]

Hi all,

My question comes from a Ninja generator build system, and is specifically 
about an internal rule generated by cmake.
What is the purpose of the RERUN_CMAKE rule generated by CMake with a Ninja 
generator?

In the current repo, the only reference to this rule is in 
WriteTargetRebuildManifest 
here
At line 1285, the rule is written out, seemingly as-is.

According to lines 1274 to 1284, the only actual behavior of this command, 
which is executed whenever the source CMakeLists.txt file, files included from 
the CMakeLists, and some other CMake installation files change, is:
cmake -S  -B 

This seems completely insufficient for "re-running" cmake. The most obvious 
flaw is the absence of the generator. When I've seen this rule fire, my Ninja 
build system adds a useless Makefile to the build system, and then (hopefully) 
continues building as if nothing had been done at all, without so much as 
inspecting that Makefile.

What about command-line arguments like -D?

Am I missing the purpose of this rule or potentially doing something 
non-standard? The reason I send an email is because this behavior is sending my 
project into a cmake loop where it detects build.ninja is out of date, re-runs 
cmake to generate a Makefile instead of a ninja build system, and then 
infinitely repeats because it never actually re-ran anything.

Thanks,
JB
Code Generation
Texas Instruments
-- 

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

[CMake] cmake end user vs. developer rpath handling

[DIXON, MARK C.]

Hi,

I install lots of software packages under Linux and, increasingly, they 
use cmake instead of other methods (congratulations!)

Frustratingly for me, I seem to keep ending up in a fight with the various 
developer's cmake config files over what rpath should be set, among other 
things. Obviously, I think I know best, so would like to know how to win 
please :)

Sometimes, this does the trick. When it does, I'm very happy:

   cmake -D CMAKE_INSTALL_RPATH="/my/rpath" source_dir

I'm currently looking at a package 
(https://github.com/PointCloudLibrary/pcl) where this has no bearing on 
the rpath of the installed software - I seem to get something set by the 
developer.

Is there a way to reliably add to, or at least override, the developer's 
rpath in any cmake-built software?

Thanks,

Mark
-- 

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

Re: [CMake] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

[Alexander]

Hi Craig,
Thank you for this information. I never tried this way with the own
CMakeLists.txt and I should try it. I found one efficient workaround
however which is the option
-DCMAKE_CXX_STANDARD_LIBRARIES=/DEF:additionalDefFile.def. It turned that
the content of CMAKE_CXX_STANDARD_LIBRARIES is pushed to the linking
command without any preprocessing which is exactly what I wanted
(reference:
https://cmake.cmake.narkive.com/UuC3PGkF/how-to-append-arbitrary-linker-options).
What about stripping of the /DEF:option from CMAKE_SHARED_LINKER_FLAGS I
see I would better ask CMake developers (cmake-develop...@cmake.org) or
submit a bug.

--
Best Regards,
Alexander

On Sat, 5 Oct 2019 at 10:33, Craig Scott  wrote:

>
>
> On Sat, Oct 5, 2019 at 12:59 AM Alexander 
> wrote:
>
>> Dear Cristian,
>>
>> It would better for me not modifying CMakeFiles.txt, because as I wrote
>> it is 3rd party stuff (we just download it and build, but some different
>> way).
>> My concern is why the command line option -DCMAKE_SHARED_LINKER_FLAGS
>> deliberately ignores /DEF: option. It this behavior expected? What is the
>> logic behind this behavior? Why not simply allow /DEF in
>> CMAKE_SHARED_LINKER_FLAGS and not cut it?
>>
>
>
> You don't have to modify the third party CMakeLists.txt file to achieve
> what Cristian suggested. You can call target_sources() on the third party
> target from your own CMakeLists.txt file to add .def files to their
> target. You don't have to be in the same directory scope as the target to
> use target_sources() on it.
>
> I'm not familiar with why CMake is stripping out the /DEF: option in your
> case, but I suspect it would be related to the way CMake expects to add
> such options based on .def files given as sources.
>
>
>
>> On Fri, 4 Oct 2019 at 16:54, Cristian Adam 
>> wrote:
>>
>>> Hi,
>>>
>>> You should simply add the my_defs.def file as a source files to
>>> add_library/add_executable.
>>> CMake will automagically pass /DEF: to the linker with my_defs.def
>>>
>>> Cheers,
>>> Cristian.
>>>
>>> On Fri, Oct 4, 2019 at 4:45 PM Alexander 
>>> wrote:
>>>
 Hello,

 I would like to add an extra .defs file for linking of a DLL on
 Windows. I want to use the CMake command line option
 -DCMAKE_SHARED_LINKER_FLAGS="/DEF:my_defs.defs". I expect that besides the
 automatically generated
 /bin/.dir/Release/exports.def i see additionally
 /DEF:my_defs.defs in the resulting linking command, but it does not happen.

 What is especially irritating that CMake deliberately removes namely
 /DEF: from CMAKE_SHARED_LINKER_FLAGS. Any other word combinations (if I
 write  /DEF111:my_defs.def for example) are accepted and I see them the
 linking command.

 I tried to reach the same goal using a CMakeLists.txt like this:

 set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def")

 but it did not help - the same way CMake removes my /DEF: option.

 Could you please open a ticket to fix this behavior to not cut /DEF:
 option from CMAKE_***_LINKER_FLAGS?

 On my opinion CMake should not interpret or modify the content of
 CMAKE_SHARED_LINKER_FLAGS value, but should put it entirely as the user
 specified it. If you have another opinion, please provide any other
 possibility to pass an arbitrary arguments to the linking command "as is"
 so that they are not modified.

 Any workaround is highly appreciated (better command-line, because we
 build 3rd party software and it would not really fine to change
 CMakeLists.txt)

 --
 Best Regards,
 Alexander Samoilov
 Build & Integration Engineer
 Compart AG, 71034 Böblingen Germany

>>>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> Get the hand-book for every CMake user: Professional CMake: A Practical
> Guide 
> Consulting services (CMake, C++, build/release processes):
> https://crascit.com/services
>
-- 

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

Re: [CMake] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

[Craig Scott]

On Sat, Oct 5, 2019 at 12:59 AM Alexander 
wrote:

> Dear Cristian,
>
> It would better for me not modifying CMakeFiles.txt, because as I wrote it
> is 3rd party stuff (we just download it and build, but some different way).
> My concern is why the command line option -DCMAKE_SHARED_LINKER_FLAGS
> deliberately ignores /DEF: option. It this behavior expected? What is the
> logic behind this behavior? Why not simply allow /DEF in
> CMAKE_SHARED_LINKER_FLAGS and not cut it?
>


You don't have to modify the third party CMakeLists.txt file to achieve
what Cristian suggested. You can call target_sources() on the third party
target from your own CMakeLists.txt file to add .def files to their target.
You don't have to be in the same directory scope as the target to use
target_sources() on it.

I'm not familiar with why CMake is stripping out the /DEF: option in your
case, but I suspect it would be related to the way CMake expects to add
such options based on .def files given as sources.



> On Fri, 4 Oct 2019 at 16:54, Cristian Adam 
> wrote:
>
>> Hi,
>>
>> You should simply add the my_defs.def file as a source files to
>> add_library/add_executable.
>> CMake will automagically pass /DEF: to the linker with my_defs.def
>>
>> Cheers,
>> Cristian.
>>
>> On Fri, Oct 4, 2019 at 4:45 PM Alexander 
>> wrote:
>>
>>> Hello,
>>>
>>> I would like to add an extra .defs file for linking of a DLL on Windows.
>>> I want to use the CMake command line option
>>> -DCMAKE_SHARED_LINKER_FLAGS="/DEF:my_defs.defs". I expect that besides the
>>> automatically generated
>>> /bin/.dir/Release/exports.def i see additionally
>>> /DEF:my_defs.defs in the resulting linking command, but it does not happen.
>>>
>>> What is especially irritating that CMake deliberately removes namely
>>> /DEF: from CMAKE_SHARED_LINKER_FLAGS. Any other word combinations (if I
>>> write  /DEF111:my_defs.def for example) are accepted and I see them the
>>> linking command.
>>>
>>> I tried to reach the same goal using a CMakeLists.txt like this:
>>>
>>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def")
>>>
>>> but it did not help - the same way CMake removes my /DEF: option.
>>>
>>> Could you please open a ticket to fix this behavior to not cut /DEF:
>>> option from CMAKE_***_LINKER_FLAGS?
>>>
>>> On my opinion CMake should not interpret or modify the content of
>>> CMAKE_SHARED_LINKER_FLAGS value, but should put it entirely as the user
>>> specified it. If you have another opinion, please provide any other
>>> possibility to pass an arbitrary arguments to the linking command "as is"
>>> so that they are not modified.
>>>
>>> Any workaround is highly appreciated (better command-line, because we
>>> build 3rd party software and it would not really fine to change
>>> CMakeLists.txt)
>>>
>>> --
>>> Best Regards,
>>> Alexander Samoilov
>>> Build & Integration Engineer
>>> Compart AG, 71034 Böblingen Germany
>>>
>>

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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide 
Consulting services (CMake, C++, build/release processes):
https://crascit.com/services
-- 

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

Re: [CMake] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

[Alexander]

Dear Cristian,

It would better for me not modifying CMakeFiles.txt, because as I wrote it
is 3rd party stuff (we just download it and build, but some different way).
My concern is why the command line option -DCMAKE_SHARED_LINKER_FLAGS
deliberately ignores /DEF: option. It this behavior expected? What is the
logic behind this behavior? Why not simply allow /DEF in
CMAKE_SHARED_LINKER_FLAGS and not cut it?

--
Best Regards,
Alexander

On Fri, 4 Oct 2019 at 16:54, Cristian Adam  wrote:

> Hi,
>
> You should simply add the my_defs.def file as a source files to
> add_library/add_executable.
> CMake will automagically pass /DEF: to the linker with my_defs.def
>
> Cheers,
> Cristian.
>
> On Fri, Oct 4, 2019 at 4:45 PM Alexander 
> wrote:
>
>> Hello,
>>
>> I would like to add an extra .defs file for linking of a DLL on Windows.
>> I want to use the CMake command line option
>> -DCMAKE_SHARED_LINKER_FLAGS="/DEF:my_defs.defs". I expect that besides the
>> automatically generated
>> /bin/.dir/Release/exports.def i see additionally
>> /DEF:my_defs.defs in the resulting linking command, but it does not happen.
>>
>> What is especially irritating that CMake deliberately removes namely
>> /DEF: from CMAKE_SHARED_LINKER_FLAGS. Any other word combinations (if I
>> write  /DEF111:my_defs.def for example) are accepted and I see them the
>> linking command.
>>
>> I tried to reach the same goal using a CMakeLists.txt like this:
>>
>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def")
>>
>> but it did not help - the same way CMake removes my /DEF: option.
>>
>> Could you please open a ticket to fix this behavior to not cut /DEF:
>> option from CMAKE_***_LINKER_FLAGS?
>>
>> On my opinion CMake should not interpret or modify the content of
>> CMAKE_SHARED_LINKER_FLAGS value, but should put it entirely as the user
>> specified it. If you have another opinion, please provide any other
>> possibility to pass an arbitrary arguments to the linking command "as is"
>> so that they are not modified.
>>
>> Any workaround is highly appreciated (better command-line, because we
>> build 3rd party software and it would not really fine to change
>> CMakeLists.txt)
>>
>> --
>> Best Regards,
>> Alexander Samoilov
>> Build & Integration Engineer
>> Compart AG, 71034 Böblingen Germany
>> --
>>
>> 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

Re: [CMake] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

[Cristian Adam]

Hi,

You should simply add the my_defs.def file as a source files to
add_library/add_executable.
CMake will automagically pass /DEF: to the linker with my_defs.def

Cheers,
Cristian.

On Fri, Oct 4, 2019 at 4:45 PM Alexander 
wrote:

> Hello,
>
> I would like to add an extra .defs file for linking of a DLL on Windows. I
> want to use the CMake command line option
> -DCMAKE_SHARED_LINKER_FLAGS="/DEF:my_defs.defs". I expect that besides the
> automatically generated
> /bin/.dir/Release/exports.def i see additionally
> /DEF:my_defs.defs in the resulting linking command, but it does not happen.
>
> What is especially irritating that CMake deliberately removes namely /DEF:
> from CMAKE_SHARED_LINKER_FLAGS. Any other word combinations (if I write
> /DEF111:my_defs.def for example) are accepted and I see them the linking
> command.
>
> I tried to reach the same goal using a CMakeLists.txt like this:
>
> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def")
>
> but it did not help - the same way CMake removes my /DEF: option.
>
> Could you please open a ticket to fix this behavior to not cut /DEF:
> option from CMAKE_***_LINKER_FLAGS?
>
> On my opinion CMake should not interpret or modify the content of
> CMAKE_SHARED_LINKER_FLAGS value, but should put it entirely as the user
> specified it. If you have another opinion, please provide any other
> possibility to pass an arbitrary arguments to the linking command "as is"
> so that they are not modified.
>
> Any workaround is highly appreciated (better command-line, because we
> build 3rd party software and it would not really fine to change
> CMakeLists.txt)
>
> --
> Best Regards,
> Alexander Samoilov
> Build & Integration Engineer
> Compart AG, 71034 Böblingen Germany
> --
>
> 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

[CMake] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

[Alexander]

Hello,

I would like to add an extra .defs file for linking of a DLL on Windows. I
want to use the CMake command line option
-DCMAKE_SHARED_LINKER_FLAGS="/DEF:my_defs.defs". I expect that besides the
automatically generated
/bin/.dir/Release/exports.def i see additionally
/DEF:my_defs.defs in the resulting linking command, but it does not happen.

What is especially irritating that CMake deliberately removes namely /DEF:
from CMAKE_SHARED_LINKER_FLAGS. Any other word combinations (if I write
/DEF111:my_defs.def for example) are accepted and I see them the linking
command.

I tried to reach the same goal using a CMakeLists.txt like this:

set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def")

but it did not help - the same way CMake removes my /DEF: option.

Could you please open a ticket to fix this behavior to not cut /DEF: option
from CMAKE_***_LINKER_FLAGS?

On my opinion CMake should not interpret or modify the content of
CMAKE_SHARED_LINKER_FLAGS value, but should put it entirely as the user
specified it. If you have another opinion, please provide any other
possibility to pass an arbitrary arguments to the linking command "as is"
so that they are not modified.

Any workaround is highly appreciated (better command-line, because we build
3rd party software and it would not really fine to change CMakeLists.txt)

--
Best Regards,
Alexander Samoilov
Build & Integration Engineer
Compart AG, 71034 Böblingen Germany
-- 

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

[CMake] Cmake error

[Enrique González]

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@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 

Re: [CMake] cmake for GHS

[fdk17]

On Thu, Aug 29, 2019, at 1:51 AM, Deepan Muthusamy (RBEI/ESP-IS44) via CMake 
wrote:
> I want to compile c and c++ code in GHS compiler for renesas controller.

> 

> For Mingw compiler, My code is compiling successfully. But I want to compile 
> for GHS.

> 

> I have compiler available at this path "C:/ghs/comp_201255_RH850".

> 

> When generate, I gave option as “specify native compiler”.

> C compiler : C:/ghs/comp_201255_RH850/ccrh850.exe

> C++ compiler: C:/ghs/comp_201255_RH850/cxrh850.exe

> 

> 

> I am getting the following error.

> 

> 

> 

> Green Hills MULTI: -A  not specified; defaulting to "arm"

> Green Hills MULTI: GHS_TARGET_PLATFORM not specified; defaulting to 
> "integrity"

> Green Hills MULTI: -T  not specified; defaulting to 
> "C:/ghs/comp_201255_RH850"

> The C compiler identification is GHS

> The CXX compiler identification is GHS

> Check for working C compiler: C:/ghs/comp_201255_RH850/ccrh850.exe

> Check for working C compiler: C:/ghs/comp_201255_RH850/ccrh850.exe -- broken

> CMake Error at 
> D:/e-bike/cmake-3.14.3-win64-x64/share/cmake-3.14/Modules/CMakeTestCCompiler.cmake:60
>  (message):
>  The C compiler
> 
>  "C:/ghs/comp_201255_RH850/ccrh850.exe"
> 
>  is not able to compile a simple test program.
> 
>  It fails with the following output:
> 
>  Change Dir: D:/e-bike/EbikeSource/src/Crc16/build/CMakeFiles/CMakeTmp
> 
>  Run Build Command(s):C:/ghs/comp_201255_RH850/gbuild.exe -top 
> CMAKE_TRY_COMPILE.top.gpj cmTC_d9171.gpj 
>  Error: Could not read target file: arm_integrity.tgt

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

> Configuring incomplete, errors occurred!

> See also "D:/e-bike/EbikeSource/src/Crc16/build/CMakeFiles/CMakeOutput.log".

> See also "D:/e-bike/EbikeSource/src/Crc16/build/CMakeFiles/CMakeError.log".

> 

> 

> 

> So How to configure GHS for CMAKE build. Please advice me in this, Thanks in 
> advace

> 

> 

> 

> 

> 

> Best regards, 
> 
> *Muthusamy Deepan
>  RBEI/ESP6
*


https://cmake.org/cmake/help/v3.15/generator/Green%20Hills%20MULTI.html

It sound's like you want to generate a GHS Multi project.
The "CMAKE__COMPILER" variables are not used for compiling GHS Multi 
projects.
The GHS build tool gbuild handles those kinds of details.

You do need to set GHS_TARGET_PLATFORM and specify the target architecture so 
that a correct GHS Multi project for your target can be built.

You can inspect the GHS example projects delivered to you as part of your GHS 
installation to determine those values.
Usually its something like "arm" and "integrity", which is one of the reasons 
those were chosen as the default.

I'd highly recommend reading the GHS manual and looking at the example projects 
to understand how a GHS Multi project works if you are not already familiar 
with it.

--
F
-- 

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

[CMake] cmake for GHS

[Deepan Muthusamy (RBEI/ESP-IS44) via CMake]

I want to compile c and c++ code in GHS compiler for renesas controller.

For Mingw compiler, My code is compiling successfully. But I want to compile 
for GHS.

I have compiler available at this path  "C:/ghs/comp_201255_RH850".

When generate, I gave option as "specify native compiler".
C compiler : C:/ghs/comp_201255_RH850/ccrh850.exe
C++ compiler: C:/ghs/comp_201255_RH850/cxrh850.exe


I am getting the following error.



Green Hills MULTI: -A  not specified; defaulting to "arm"
Green Hills MULTI: GHS_TARGET_PLATFORM not specified; defaulting to "integrity"
Green Hills MULTI: -T  not specified; defaulting to 
"C:/ghs/comp_201255_RH850"
The C compiler identification is GHS
The CXX compiler identification is GHS
Check for working C compiler: C:/ghs/comp_201255_RH850/ccrh850.exe
Check for working C compiler: C:/ghs/comp_201255_RH850/ccrh850.exe -- broken
CMake Error at 
D:/e-bike/cmake-3.14.3-win64-x64/share/cmake-3.14/Modules/CMakeTestCCompiler.cmake:60
 (message):
The C compiler

"C:/ghs/comp_201255_RH850/ccrh850.exe"

is not able to compile a simple test program.

It fails with the following output:

Change Dir: D:/e-bike/EbikeSource/src/Crc16/build/CMakeFiles/CMakeTmp

Run Build Command(s):C:/ghs/comp_201255_RH850/gbuild.exe -top 
CMAKE_TRY_COMPILE.top.gpj cmTC_d9171.gpj
Error: Could not read target file: arm_integrity.tgt

CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:6 (project)
Configuring incomplete, errors occurred!
See also "D:/e-bike/EbikeSource/src/Crc16/build/CMakeFiles/CMakeOutput.log".
See also "D:/e-bike/EbikeSource/src/Crc16/build/CMakeFiles/CMakeError.log".



So How to configure GHS for CMAKE build. Please advice me in this, Thanks in 
advace





Best regards,

Muthusamy Deepan
RBEI/ESP6


-- 

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

[CMake] CMAKE+WIX RUN A PROGRAM AFTER INSTALL SUCCEEDS

[kennedy kituyi via CMake]

Hi how do I configure cpack in cmake to execute a custom command in the install 
directory.
I want to install windows service that is packaged within my installer and 
extracted to specific install location.
Thanks in advance

Sent from Mail for Windows 10

-- 

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

[CMake] Cmake Path Please

[J Decker]

THere's (some) error messages that don't include the full path of the
CMakeLists.txt, so I don't know what 'top level' is.

It would be nice if CMakeLists.txt had the full ${CMAKE_SOURCE_DIR} (?)
prepended to it.

This is built as an external project of another top level project, which
itself is built from some other top level cmakelists.txt.

```
[636/1094] Performing configure step for 'sack_vfs_command_portable'
CMake Warning (dev) in CMakeLists.txt:
  No project() command is present.  The top-level CMakeLists.txt file must
  contain a literal, direct call to the project() command.  Add a line of
  code such as

project(ProjectName)

  near the top of the file, but after cmake_minimum_required().

  CMake is pretending there is a "project(Project)" command on the first
  line.
```
-- 

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

Re: [CMake] cmake + ninja how to use several CPU cores?

[Alan W. Irwin]

On 2019-07-29 15:32-0400 Brad King wrote:


[...]We don't know what `main.cpp` includes
until after compiling it, by which point it is too late.  It could have
`#include "anything.txt"` for example.  CMake must add these pessimistic
dependencies to ensure a correct build.


Is this the real reason why even the simplest
no_custom_add_internal_library project (with nothing custom at all)
still demonstrates the issue?

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
__
--

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

Re: [CMake] cmake + ninja how to use several CPU cores?

[Dave Milter]

On Mon, Jul 29, 2019 at 10:32 PM Brad King  wrote:
>
> Even if we had that information we don't know what `main.cpp` includes
> until after compiling it, by which point it is too late.  It could have
> `#include "anything.txt"` for example.  CMake must add these pessimistic
> dependencies to ensure a correct build.
>
> The only way to avoid this is to tell CMake that there are no dependencies
> for compiling an object file by moving it to an object library that does
> not depend on any of the targets with custom commands.
>

But my custom command OUTPUT is shared library,
and in my case it would be strange to '#include' it into some source file.
So what about EXPLICIT_DEPENDS_ONLY mentioned
https://gitlab.kitware.com/cmake/cmake/issues/17097
to mark something that no way to be included into source file?
-- 

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

Re: [CMake] cmake + ninja how to use several CPU cores?

[Alan W. Irwin]

On 2019-07-29 13:24-0400 Brad King wrote:


On 7/29/19 11:50 AM, Dave Milter wrote:

Only source code are generated, so main.cpp -> main.cpp.o doesn't
depend on anything.
But generated by cmake build.ninja still require link of extern_lib
before starting  main.cpp -> main.cpp.o


If there are any custom commands in any targets on which main.cpp's
target depends then CMake must pessimistically assume that the
custom commands may generate a header needed to compile `main.cpp`.


Hi Brad:

Thanks for that clarification.  Clearly David's test case for an external 
library and my own
recently corrected test case for an internal library are not consistent with 
that assumption which
explains the bad results we get for them.

However, I think there is still a problem when a project is consistent
with that assumption.  See the attached no_custom_add_internal_library.tar.gz
which contains an extremely simple test project with no custom commands at all
(i.e., no wait and headers and source are pre-existing in all cases).

Yet for this project I get the following results with ninja.

irwin@merlin> ninja -j16 -v app
[1/7] /usr/bin/c++  -Dinternal_lib_EXPORTS -I../lib -fPIC -MD -MT 
CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -MF 
CMakeFiles/internal_lib.dir/lib/lib4.cpp.o.d -o 
CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -c ../lib/lib4.cpp
[2/7] /usr/bin/c++  -Dinternal_lib_EXPORTS -I../lib -fPIC -MD -MT 
CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -MF 
CMakeFiles/internal_lib.dir/lib/lib1.cpp.o.d -o 
CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -c ../lib/lib1.cpp
[3/7] /usr/bin/c++  -Dinternal_lib_EXPORTS -I../lib -fPIC -MD -MT 
CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -MF 
CMakeFiles/internal_lib.dir/lib/lib2.cpp.o.d -o 
CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -c ../lib/lib2.cpp
[4/7] /usr/bin/c++  -Dinternal_lib_EXPORTS -I../lib -fPIC -MD -MT 
CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -MF 
CMakeFiles/internal_lib.dir/lib/lib3.cpp.o.d -o 
CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -c ../lib/lib3.cpp
[5/7] : && /usr/bin/c++ -fPIC-shared -Wl,-soname,libinternal_lib.so -o 
libinternal_lib.so CMakeFiles/internal_lib.dir/lib/lib1.cpp.o 
CMakeFiles/internal_lib.dir/lib/lib2.cpp.o CMakeFiles/internal_lib.dir/lib/lib3.cpp.o 
CMakeFiles/internal_lib.dir/lib/lib4.cpp.o   && :
[6/7] /usr/bin/c++   -I../lib  -MD -MT CMakeFiles/app.dir/main.cpp.o -MF 
CMakeFiles/app.dir/main.cpp.o.d -o CMakeFiles/app.dir/main.cpp.o -c ../main.cpp
[7/7] : && /usr/bin/c++ CMakeFiles/app.dir/main.cpp.o  -o app  
-Wl,-rpath,/home/irwin/David.Milter/20190728/test_ninja/no_gen_add_internal_library/build_dir 
libinternal_lib.so && :

irwin@merlin> grep cmake_object_order_depends_target_app build.ninja 
build cmake_object_order_depends_target_app: phony || cmake_object_order_depends_target_internal_lib

build CMakeFiles/app.dir/main.cpp.o: CXX_COMPILER__app ../main.cpp || 
cmake_object_order_depends_target_app

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
__
--

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

Re: [CMake] cmake + ninja how to use several CPU cores?

[Brad King]

On 7/29/19 3:22 PM, Dave Milter wrote:
>> Since then all objects in a target can start compiling independently
>> so long as that target does not depend on any targets with custom
>> commands.

See also https://gitlab.kitware.com/cmake/cmake/issues/17097

> Is any way to tell cmake that add_custom_command is have no side effect,
> and OUTPUT is exactly what it produces?

Even if we had that information we don't know what `main.cpp` includes
until after compiling it, by which point it is too late.  It could have
`#include "anything.txt"` for example.  CMake must add these pessimistic
dependencies to ensure a correct build.

The only way to avoid this is to tell CMake that there are no dependencies
for compiling an object file by moving it to an object library that does
not depend on any of the targets with custom commands.

-Brad
-- 

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

Re: [CMake] cmake + ninja how to use several CPU cores?

[Dave Milter]

On Mon, Jul 29, 2019 at 8:24 PM Brad King  wrote:
>
> CMake 3.9 made this much better than it used to be:
>
>   https://gitlab.kitware.com/cmake/cmake/merge_requests/430
>
> Since then all objects in a target can start compiling independently
> so long as that target does not depend on any targets with custom
> commands.

Is any way to tell cmake that add_custom_command is have no side effect,
and OUTPUT is exactly what it produces?

I see that there is
Tests/RunCMake/Ninja/LooseObjectDepends.cmake

in https://gitlab.kitware.com/cmake/cmake/merge_requests/430

is it negative test, or there is chance for fast compilation?
-- 

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

Re: [CMake] cmake + ninja how to use several CPU cores?

[Alan W. Irwin]

On 2019-07-29 18:50+0300 Dave Milter wrote:


On Mon, Jul 29, 2019 at 1:48 PM Bruce Stephens
 wrote:


I think it's reasonable for CMake/Ninja to require the headers be
generated, especially since main.cpp does include one of them (though
CMake/Ninja doesn't know that until later). lib/lib1.cpp is more
arguable, but I imagine there's no real distinction made: main.cpp.o
depends on all the dependencies of the libraries.



In my initial example headers files are not generated in cmake scripts.
Only source code are generated, so main.cpp -> main.cpp.o doesn't
depend on anything.
But generated by cmake build.ninja still require link of extern_lib
before starting  main.cpp -> main.cpp.o


Thanks, Bruce, for spotting that issue with the first version of my
simple example which I oversimplified.  I have
now corrected it (see attached tarball) to follow the use case of
pre-existing headers and an app that links to a library (internal for
my corrected test case, and external for David's test case).

The issue (compilation of main.cpp is unreasonably delayed for
parallel builds until after the library (internal or external) is
built) still shows up in my corrected test case for both -G"Ninja" and
-G"Unix Makefiles" just like happens for David's test case for an
external library.

So the question remains why does CMake constrain parallel builds this
way (to the point that it is a bottlneck for David's real project with
external libraries) for this general use case?

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
__

corrected_add_internal_library.tar.gz
Description: tarball containing corrected test case of app with pre-existing headers and internal library
-- 

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

Re: [CMake] cmake + ninja how to use several CPU cores?

[Brad King]

On 7/29/19 11:50 AM, Dave Milter wrote:
> Only source code are generated, so main.cpp -> main.cpp.o doesn't
> depend on anything.
> But generated by cmake build.ninja still require link of extern_lib
> before starting  main.cpp -> main.cpp.o

If there are any custom commands in any targets on which main.cpp's
target depends then CMake must pessimistically assume that the
custom commands may generate a header needed to compile `main.cpp`.
Object libraries can be used to break the dependencies that lead
to the assumption.

CMake 3.9 made this much better than it used to be:

  https://gitlab.kitware.com/cmake/cmake/merge_requests/430

Since then all objects in a target can start compiling independently
so long as that target does not depend on any targets with custom
commands.

-Brad
-- 

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

Re: [CMake] cmake + ninja how to use several CPU cores?

[Dave Milter]

On Mon, Jul 29, 2019 at 1:48 PM Bruce Stephens
 wrote:
>
> I think it's reasonable for CMake/Ninja to require the headers be
> generated, especially since main.cpp does include one of them (though
> CMake/Ninja doesn't know that until later). lib/lib1.cpp is more
> arguable, but I imagine there's no real distinction made: main.cpp.o
> depends on all the dependencies of the libraries.
>

In my initial example headers files are not generated in cmake scripts.
Only source code are generated, so main.cpp -> main.cpp.o doesn't
depend on anything.
But generated by cmake build.ninja still require link of extern_lib
before starting  main.cpp -> main.cpp.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

Re: [CMake] cmake + ninja how to use several CPU cores?

[Bruce Stephens]

You might find it interesting to look at build.ninja. By the looks of
it there's a (phony) target guving the dependencies of the library.
(That's called cmake_object_order_depends_target_internal_lib) and
CMakeFiles/app.dir/main.cpp.o is depending on that.

Presumably the idea is that there's no point trying to compile
main.cpp before we could build the library, since (as in this case)
that might require generated headers which main.cpp might need.

If I get rid of the wait5 thing, then main.cpp gets compiled (using
"ninja -v CMakeFiles/app.dir/main.cpp.o") without the library. Just
the headers (and lib/lib1.cpp) get generated.

I think it's reasonable for CMake/Ninja to require the headers be
generated, especially since main.cpp does include one of them (though
CMake/Ninja doesn't know that until later). lib/lib1.cpp is more
arguable, but I imagine there's no real distinction made: main.cpp.o
depends on all the dependencies of the libraries.

On Mon, 29 Jul 2019 at 10:34, Alan W. Irwin  wrote:
>
> On 2019-07-28 23:39-0700 Alan W. Irwin wrote:
>
> > @Both: I also plan to look at whether this issue exists for
> > the internal library case so more later when I get that
> > corresponding simple test project implemented.
>
> @Brad and David:
>
> I have now implemented a simple test project for the internal library
> case.  See the attached tarball (and please let me know if your input
> mail software chain allows you to receive that tarball).  In general I
> think this test case improves somewhat on Dave's test project by
> making the sleep more explicit at the CMake level, generating the
> headers explicitly rather than including them in the tarball,
> generating all header and source code files and the library (internal
> in this case) within the build tree rather than source tree (which
> considerably simplifies making a clean start), and by allowing the
> user to specify the -DBUILD_SHARED_LIBS=ON (or OFF) cmake option to
> choose whether the library is built shared on static.  (Of course,
> none of these improvements should affect the delayed compilation
> issue.)
>
> For this new simple test project, here are the results for the -G"Ninja" case 
> (when -DBUILD_SHARED_LIBS=ON is specified):
>
> irwin@merlin> ninja -j16 -v app
> [1/10] cd 
> /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir/lib
>  && sh 
> /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/lib/include_generator.sh
> [2/10] cd 
> /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir/lib
>  && sh 
> /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/lib/lib_generator.sh
> [3/10] cd 
> /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir 
> && sleep 5
> [4/10] /usr/bin/c++  -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT 
> CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -MF 
> CMakeFiles/internal_lib.dir/lib/lib1.cpp.o.d -o 
> CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -c lib/lib1.cpp
> [5/10] /usr/bin/c++  -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT 
> CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -MF 
> CMakeFiles/internal_lib.dir/lib/lib3.cpp.o.d -o 
> CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -c lib/lib3.cpp
> [6/10] /usr/bin/c++  -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT 
> CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -MF 
> CMakeFiles/internal_lib.dir/lib/lib4.cpp.o.d -o 
> CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -c lib/lib4.cpp
> [7/10] /usr/bin/c++  -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT 
> CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -MF 
> CMakeFiles/internal_lib.dir/lib/lib2.cpp.o.d -o 
> CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -c lib/lib2.cpp
> [8/10] : && /usr/bin/c++ -fPIC-shared -Wl,-soname,libinternal_lib.so -o 
> libinternal_lib.so CMakeFiles/internal_lib.dir/lib/lib1.cpp.o 
> CMakeFiles/internal_lib.dir/lib/lib2.cpp.o 
> CMakeFiles/internal_lib.dir/lib/lib3.cpp.o 
> CMakeFiles/internal_lib.dir/lib/lib4.cpp.o   && :
> [9/10] /usr/bin/c++   -Ilib  -MD -MT CMakeFiles/app.dir/main.cpp.o -MF 
> CMakeFiles/app.dir/main.cpp.o.d -o CMakeFiles/app.dir/main.cpp.o -c 
> ../main.cpp
> [10/10] : && /usr/bin/c++ CMakeFiles/app.dir/main.cpp.o  -o app  
> -Wl,-rpath,/home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir
>  libinternal_lib.so && :
>
> Note that the build of main.cpp.o is (unreasonably in my opinion) delayed to 
> step 9.
>
> And that build is similarly delayed in the -G"Unix Makefiles" case.
> That is this newly implemented test case for the internal library
> build shows exactly the same unexplained compilation delays for
> main.cpp for both -G"Ninja" and -G"Unix Makefiles" as David's test
> case for the external library build.
>
> @Brad and other CMake developers who might be lurking here:
>
> Can anybody explain why CMake has this delayed compilation "feature"
> for apps that depend on internal or external libraries, and if there
> is no compelling reason for it would it be straightforward to 

Re: [CMake] cmake + ninja how to use several CPU cores?

[Alan W. Irwin]

On 2019-07-28 23:39-0700 Alan W. Irwin wrote:


@Both: I also plan to look at whether this issue exists for
the internal library case so more later when I get that
corresponding simple test project implemented.


@Brad and David:

I have now implemented a simple test project for the internal library
case.  See the attached tarball (and please let me know if your input
mail software chain allows you to receive that tarball).  In general I
think this test case improves somewhat on Dave's test project by
making the sleep more explicit at the CMake level, generating the
headers explicitly rather than including them in the tarball,
generating all header and source code files and the library (internal
in this case) within the build tree rather than source tree (which
considerably simplifies making a clean start), and by allowing the
user to specify the -DBUILD_SHARED_LIBS=ON (or OFF) cmake option to
choose whether the library is built shared on static.  (Of course,
none of these improvements should affect the delayed compilation
issue.)

For this new simple test project, here are the results for the -G"Ninja" case 
(when -DBUILD_SHARED_LIBS=ON is specified):

irwin@merlin> ninja -j16 -v app
[1/10] cd 
/home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir/lib 
&& sh 
/home/irwin/David.Milter/20190728/test_ninja/add_internal_library/lib/include_generator.sh
[2/10] cd 
/home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir/lib 
&& sh 
/home/irwin/David.Milter/20190728/test_ninja/add_internal_library/lib/lib_generator.sh
[3/10] cd /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir 
&& sleep 5
[4/10] /usr/bin/c++  -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT 
CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -MF 
CMakeFiles/internal_lib.dir/lib/lib1.cpp.o.d -o 
CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -c lib/lib1.cpp
[5/10] /usr/bin/c++  -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT 
CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -MF 
CMakeFiles/internal_lib.dir/lib/lib3.cpp.o.d -o 
CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -c lib/lib3.cpp
[6/10] /usr/bin/c++  -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT 
CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -MF 
CMakeFiles/internal_lib.dir/lib/lib4.cpp.o.d -o 
CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -c lib/lib4.cpp
[7/10] /usr/bin/c++  -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT 
CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -MF 
CMakeFiles/internal_lib.dir/lib/lib2.cpp.o.d -o 
CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -c lib/lib2.cpp
[8/10] : && /usr/bin/c++ -fPIC-shared -Wl,-soname,libinternal_lib.so -o 
libinternal_lib.so CMakeFiles/internal_lib.dir/lib/lib1.cpp.o 
CMakeFiles/internal_lib.dir/lib/lib2.cpp.o CMakeFiles/internal_lib.dir/lib/lib3.cpp.o 
CMakeFiles/internal_lib.dir/lib/lib4.cpp.o   && :
[9/10] /usr/bin/c++   -Ilib  -MD -MT CMakeFiles/app.dir/main.cpp.o -MF 
CMakeFiles/app.dir/main.cpp.o.d -o CMakeFiles/app.dir/main.cpp.o -c ../main.cpp
[10/10] : && /usr/bin/c++ CMakeFiles/app.dir/main.cpp.o  -o app  
-Wl,-rpath,/home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir 
libinternal_lib.so && :

Note that the build of main.cpp.o is (unreasonably in my opinion) delayed to 
step 9.

And that build is similarly delayed in the -G"Unix Makefiles" case.
That is this newly implemented test case for the internal library
build shows exactly the same unexplained compilation delays for
main.cpp for both -G"Ninja" and -G"Unix Makefiles" as David's test
case for the external library build.

@Brad and other CMake developers who might be lurking here:

Can anybody explain why CMake has this delayed compilation "feature"
for apps that depend on internal or external libraries, and if there
is no compelling reason for it would it be straightforward to remove
it?

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
__

add_internal_library.tar.gz
Description: tarball for newly implemented simple test case for internal library + app
-- 

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 

Re: [CMake] cmake + ninja how to use several CPU cores?

[Alan W. Irwin]

Hi to Dave and Brad:

@Dave: As you are probably already aware Brad is one of the primary
CMake developers so I think he should be in on this discussion.

@Brad:

Using Dave's simple test project
I confirmed the compilation delay issue below in detail for both the
-G"Ninja" case AND the -G"Unix Makefiles" case on Debian Buster.
Would you please take a look at this simple test case to see if you
can find the explanation for this issue?


After years of ignoring CMake + Ninja because of the Fortran issues
for that combination, I have just realized you have a fork of Ninja
(not yet merged upstream) which apparently works well with CMake for the Fortran
case.  So I am in the process of trying that Ninja fork out for all components 
of PLplot
(including our Fortran binding and examples), and I plan to report to you those
results in a separate thread.  Which explains my renewed interest in Ninja
(in this case not your fork since no Fortran is involved) for this current 
thread.


@Both: I also plan to look at whether this issue exists for
the internal library case so more later when I get that
corresponding simple test project implemented.

More details below concerning the external library case 

On 2019-07-29 03:36+0300 Dave Milter wrote:


Hi,

On Mon, Jul 29, 2019 at 12:01 AM Alan W. Irwin
 wrote:


On 2019-07-28 19:03+0300 Dave Milter wrote:

To help answer your question, I see no fundamental issues with your code above.

If the latter is really true, that appears to me to be a CMake bug
(although I cannot make the final judgement call on that since I am an
experienced CMake user rather than a CMake developer).  And if so, does that
same problem (unnecessary delay in compilation rather than linking)
occur for the following simplified case?



In fact my code in previous email is demo code. It already contains
"sleep" inside lib_generator.sh to emulate
real project.


@Dave:

Great minds think alike concerning clearly demonstrating this issue with the
help of the sleep command.  :-)


I am just not sure is this good idea to send attachment into this mailing list.


Actually, for obvious reasons of convenience, gzipped tarball
attachments should never be an issue on mailing lists (like the CMake
ones) which are relevant to discussion of software.  (There are
typically mailing-list limits with regard to size, but they are
normally quite generous so I have never run into this issue on the
CMake mailing lists.  Therefore, as expected, your attachment got
through to me without issues.  Also, I double-checked your description
of that attachment which is critical for the input mail chains of some
users.  In your case that description (which you can configure with
your mail software) was "application/GZIP" which is obviously fine for
my input mail chain case and presumably most others on this list who
want to look at that attachment.

@Brad: have you had any trouble seeing that attachment without your
input mail chain stripping it out?


See attachment, it is possible only to build on Linux/Mac, because of
usage bash/gcc for lib_geneator.sh

And I am pretty sure that problem in cmake (or my usage of cmake),
because of build.ninja generated by cmake contains such rules:
```
build cmake_object_order_depends_target_app: phony || extern_lib_target

build CMakeFiles/app.dir/main.cpp.o: CXX_COMPILER__app ../main.cpp ||
cmake_object_order_depends_target_app
```
"||" is "order-only dependencies" according to
https://ninja-build.org/manual.html#_syntax_example .
So cmake instruct ninja do not build main.cpp.o untill extern_lib_target build.


@Dave: Thanks very much for that simple test project.

@Both:

I configured and built it using the Debian Buster = Stable system
versions of cmake (version 3.13.4) and ninja (version 1.8.2) using the
following commands

I. The -G"Ninja" case

# Fresh start:
# IMPORTANT: first cd to the top-level directory of the source tree. Then

# Get rid of the previously generated external library (if any) to
# insure the 5 second pause associated with that generation always
# occurs.
rm -f extern_lib/libextern.so

# Start with an empty build tree

rm -rf build_dir
mkdir build_dir
cd build_dir

# Configure
time cmake -G"Ninja" .. >& cmake.out
==>

real0m1.084s
user0m0.845s
sys 0m0.232s

# Just to be specific (although ninja normally figures this out for itself for 
parallel builds)
# build with -j16 since I have 16-thread hardware.  Also use -v option to 
create (slightly more)
# verbose output.
time ninja -j16 -v all
==>

[1/3] cd /home/irwin/David.Milter/20190728/test_ninja/add_library_imported/extern_lib 
&& sh ./lib_generator.sh
Generating...
Generating...DONE
[2/3] /usr/bin/c++   -isystem ../extern_lib/gen  -MD -MT 
CMakeFiles/app.dir/main.cpp.o -MF CMakeFiles/app.dir/main.cpp.o.d -o 
CMakeFiles/app.dir/main.cpp.o -c ../main.cpp
[3/3] : && /usr/bin/c++ CMakeFiles/app.dir/main.cpp.o  -o app  

Re: [CMake] cmake + ninja how to use several CPU cores?

[Dave Milter]

Hi,

On Mon, Jul 29, 2019 at 12:01 AM Alan W. Irwin
 wrote:
>
> On 2019-07-28 19:03+0300 Dave Milter wrote:
>
> To help answer your question, I see no fundamental issues with your code 
> above.
>
> If the latter is really true, that appears to me to be a CMake bug
> (although I cannot make the final judgement call on that since I am an
> experienced CMake user rather than a CMake developer).  And if so, does that
> same problem (unnecessary delay in compilation rather than linking)
> occur for the following simplified case?
>

In fact my code in previous email is demo code. It already contains
"sleep" inside lib_generator.sh to emulate
real project.
I am just not sure is this good idea to send attachment into this mailing list.
See attachment, it is possible only to build on Linux/Mac, because of
usage bash/gcc for lib_geneator.sh

And I am pretty sure that problem in cmake (or my usage of cmake),
because of build.ninja generated by cmake contains such rules:
```
build cmake_object_order_depends_target_app: phony || extern_lib_target

build CMakeFiles/app.dir/main.cpp.o: CXX_COMPILER__app ../main.cpp ||
cmake_object_order_depends_target_app
```
"||" is "order-only dependencies" according to
https://ninja-build.org/manual.html#_syntax_example .
So cmake instruct ninja do not build main.cpp.o untill extern_lib_target build.


add_library_imported.tar.gz
Description: application/gzip
-- 

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

Re: [CMake] cmake + ninja how to use several CPU cores?

[Alan W. Irwin]

On 2019-07-28 19:03+0300 Dave Milter wrote:


Hi,

I heard that ninja has great feature it allows build continue without
wainting full link.

So if you have library Lib and executable App,
source code of App may build in parallel with source code of Lib,
and sync only link stage. While other build systems force build of Lib,
and only then start build of any object files of App.

But is it possible to use this feature with cmake?

Here my cmake code to emulate bottleneck of our build:

```
cmake_minimum_required(VERSION 3.12 FATAL_ERROR)
project(imported)

set(EXTERN_LIB_FILE ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib/libextern.so)
set(EXTERN_LIB_INCLUDES ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib/gen)
add_custom_command(OUTPUT  ${EXTERN_LIB_FILE}
  COMMAND sh ./lib_generator.sh
  WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib)
add_custom_target(extern_lib_target DEPENDS ${EXTERN_LIB_FILE})
add_library(extern_lib SHARED IMPORTED GLOBAL)
add_dependencies(extern_lib extern_lib_target)

set_target_properties(extern_lib
   PROPERTIES
   IMPORTED_LOCATION ${EXTERN_LIB_FILE}
   INTERFACE_INCLUDE_DIRECTORIES ${EXTERN_LIB_INCLUDES})
add_executable(app main.cpp)
target_link_libraries(app extern_lib)
```

we use not C/C++ library as part of our source tree,
and it builds some time,
so I expect that ninja can run "main.cpp" -> main.o compilation during
"extern_lib" build,
but this is not happens.

Is cmake has problem with add_custom_command and ninja,
or the whole idea is wrong, and cmake + ninja can not work in this way,
and I should use some other project generator instead of cmake for this?


Hi Dave:

To help answer your question, I see no fundamental issues with your code above.

The

add_dependencies(extern_lib extern_lib_target)

command in your above code means that the external project that is
created by building the extern_lib_target target must be *entirely*
completed before the extern_lib target
is built.  Furthermore, the

target_link_libraries(app extern_lib)

command means extern_lib must be built before the app is linked which, of
course, is a complete necessity.

However, I don't see anything in your CMake code that demands that the
compilation of main.cpp must be delayed until extern_lib is built.  So
can you double-check that the bottleneck is not actually the
(necessary until external_lib is built) delay of linking of app rather
than some unneccessary delay in the compilation of main.cpp?

If the latter is really true, that appears to me to be a CMake bug
(although I cannot make the final judgement call on that since I am an
experienced CMake user rather than a CMake developer).  And if so, does that
same problem (unnecessary delay in compilation rather than linking)
occur for the following simplified case?

cmake_minimum_required(VERSION 3.12 FATAL_ERROR)
project(test_internal_library)

# Delay 10 seconds so that it is obvious if main.cpp compilation is
# being unnecessarily delayed.

# You should introduce boolean CMake logic here to
# use the equivalent (see
# 
)
# "timeout 10" command for the Windows case.
add_custom_target(delay
COMMAND sleep 10
)

add_library(intern_lib SHARED ${)

# Add a 10 second delay until intern_lib is built
add_dependency(intern_lib delay)
add_executable(app main.cpp)
target_link_libraries(app intern_lib)

Also, please organize both test cases as tarballs containing simple
examples (including a simplified lib_generator.sh for the first case,
a 10 second delay inserted in that case as well, and simplified source
code for library (e.g., containing one function to return the "hello,
world" string and a simplified app (a main routine to print out that
string) for both cases).  Such self-contained test projects make it
much more convenient for others to confirm the issue you have
discovered on the platforms they have access to.  For example, if you
supply such self-contained test cases, I would be happy to run both
test cases here on my Linux platform for both ninja and make.  (I have
had a lot of success with parallel builds for the make case on Linux
which is why I would like to also test make just in case it turns out
you have found a ninja-only CMake bug.)

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
__
--

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 

[CMake] cmake + ninja how to use several CPU cores?

[Dave Milter]

Hi,

I heard that ninja has great feature it allows build continue without
wainting full link.

So if you have library Lib and executable App,
source code of App may build in parallel with source code of Lib,
and sync only link stage. While other build systems force build of Lib,
and only then start build of any object files of App.

But is it possible to use this feature with cmake?

Here my cmake code to emulate bottleneck of our build:

```
cmake_minimum_required(VERSION 3.12 FATAL_ERROR)
project(imported)

set(EXTERN_LIB_FILE ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib/libextern.so)
set(EXTERN_LIB_INCLUDES ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib/gen)
add_custom_command(OUTPUT  ${EXTERN_LIB_FILE}
   COMMAND sh ./lib_generator.sh
   WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib)
add_custom_target(extern_lib_target DEPENDS ${EXTERN_LIB_FILE})
add_library(extern_lib SHARED IMPORTED GLOBAL)
add_dependencies(extern_lib extern_lib_target)

set_target_properties(extern_lib
PROPERTIES
IMPORTED_LOCATION ${EXTERN_LIB_FILE}
INTERFACE_INCLUDE_DIRECTORIES ${EXTERN_LIB_INCLUDES})
add_executable(app main.cpp)
target_link_libraries(app extern_lib)
```

we use not C/C++ library as part of our source tree,
and it builds some time,
so I expect that ninja can run "main.cpp" -> main.o compilation during
"extern_lib" build,
but this is not happens.

Is cmake has problem with add_custom_command and ninja,
or the whole idea is wrong, and cmake + ninja can not work in this way,
and I should use some other project generator instead of cmake for this?
-- 

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

[CMake] CMake (cmake-gui) silently crashes on Windows 10

[Elisha Sarkis]

After months of working correctly I've found that running CMake in GUI form
on Windows 10 suddenly began silently crashing on every launch. It does not
appear to be the fault of a recent Windows update given an associate of
mine has experienced the same issue in an older version of Windows 10.

I installed CMake 3.15.0-rc4 as well as the stable 3.14.6 release,
uninstalled, and reinstalled them to no success. The same issue persists in
launching Windows in safe mode, and still persists after performing
registry fixes.

Resetting my Windows 10 install solved the problem, at least for now.

Has anyone experienced this issue, and if so have you found a solution that
doesn't involve resetting the Windows 10 OS installation?
Elisha Sarkis
-- 

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

Re: [CMake] cmake - two targets that depends on single static library that should be compiled based on the target that is being built

[Marc Herbert]

>
>
> I have a static library and two target executables, let's call them
> **libA**, **EXE1**, **EXE2**.
>
> If I am building EXE2, I need to disabled the macros in libA and don't
> link to another library.
> [...]
> I don't want to create two targets with same source files.
>

I'm curious why you wanted two executable targets but not the corresponding
two library targets, I don't think you said why. I would have thought you'd
want A. either to be able to build both configurations at the same time, B.
or one project configuration at a time. So why want A for executables but B
for libraries?
-- 

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

Re: [CMake] CMake guidelines and design patterns - recommendations?

[Sik]

https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/

On Thu, Jul 11, 2019 at 1:56 PM hex  wrote:

> hello community,
>
>
> Does anyone have a book recommendation for modern CMake with focus on
> design patterns?
>
>
> thank you
>
> --
>
> 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

Re: [CMake] CMake guidelines and design patterns - recommendations?

[Mateusz Loskot]

https://crascit.com/professional-cmake/

And search for Daniel Pfeifer's talk on YouTube

Mateusz Loskot, mate...@loskot.net
(Sent from mobile, may suffer from top-posting)

On Thu, 11 Jul 2019, 12:56 hex,  wrote:

> hello community,
>
>
> Does anyone have a book recommendation for modern CMake with focus on
> design patterns?
>
>
> thank you
>
> --
>
> 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

[CMake] CMake guidelines and design patterns - recommendations?

[hex]

hello community,


Does anyone have a book recommendation for modern CMake with focus on 
design patterns?



thank you

--

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

[CMake] CMake APT Repository Signing Key

[Kyle Edwards]

All,

The new 2020 signing key for the APT repository
(https://apt.kitware.com/) has been generated for 2020, with
fingerprint A8E5EF3A02600268. The 2019 key, with fingerprint
C1F34CDD40CD72DA, will remain in effect until the beginning of 2020, at
which point the 2020 key will go into effect. The  The 2018 key, with
fingerprint 461FD00B2DB57A2D, has been retired, and will see no further
use.

As a reminder, we recommend that you install the kitware-archive-
keyring package from the APT repository, which will ensure that your
keyring always stays up to date as we rotate our keys. The kitware-
archive-keyring package has been updated to reflect these changes. The
new version is 2019.07.03.

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

Re: [CMake] cmake - two targets that depends on single static library that should be compiled based on the target that is being built

[ugesh reddy]

Ok, seems there is no other way then. Thank you for the clarification.

On Tue, Jul 2, 2019 at 3:44 PM Kyle Edwards 
wrote:

> On Tue, 2019-07-02 at 14:18 +0200, ugesh reddy wrote:
> > Hello,
> >
> > I couldn't find any solution's for this problem even after posting
> > the question on Reddit/stack overflow, so I am posting it here.
> >
> > My question is as follows:
> >
> > I have a static library and two target executables, let's call them
> > **libA**, **EXE1**, **EXE2**.
> >
> > **libA** has pre-processor macros which needs to be enabled or
> > disabled and another static library which needs to be linked or
> > ignored based on the target executable that I am building.
> >
> > Let's say, if I am building EXE1. Then I need to enable the macros in
> > libA and link another static library to it.
> >
> > If I am building EXE2, I need to disabled the macros in libA and
> > don't link to another library.
> >
> > I don't want to create two targets with same source files.
>
> I'm sorry to say it, but creating two targets is actually exactly what
> you want to do here. If your concern is code duplication, you can make
> the code much shorter by using variables. Example:
>
> set(libA_SRCS
>   src1.c
>   src2.c
>   src3.c
>   # lots of other sources...
>   )
> add_library(libA1 STATIC ${libA_SRCS})
> target_link_libraries(libA1 otherlib)
> add_library(libA2 STATIC ${libA_SRCS})
>
> Kyle
>


-- 
 Ugesh
-- 

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

Re: [CMake] cmake - two targets that depends on single static library that should be compiled based on the target that is being built

[Kyle Edwards]

On Tue, 2019-07-02 at 14:18 +0200, ugesh reddy wrote:
> Hello,
> 
> I couldn't find any solution's for this problem even after posting
> the question on Reddit/stack overflow, so I am posting it here.
> 
> My question is as follows:
> 
> I have a static library and two target executables, let's call them
> **libA**, **EXE1**, **EXE2**.
> 
> **libA** has pre-processor macros which needs to be enabled or
> disabled and another static library which needs to be linked or
> ignored based on the target executable that I am building.
> 
> Let's say, if I am building EXE1. Then I need to enable the macros in
> libA and link another static library to it.
> 
> If I am building EXE2, I need to disabled the macros in libA and
> don't link to another library.
> 
> I don't want to create two targets with same source files.

I'm sorry to say it, but creating two targets is actually exactly what
you want to do here. If your concern is code duplication, you can make
the code much shorter by using variables. Example:

set(libA_SRCS
  src1.c
  src2.c
  src3.c
  # lots of other sources...
  )
add_library(libA1 STATIC ${libA_SRCS})
target_link_libraries(libA1 otherlib)
add_library(libA2 STATIC ${libA_SRCS})

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

[CMake] cmake - two targets that depends on single static library that should be compiled based on the target that is being built

[ugesh reddy]

Hello,

I couldn't find any solution's for this problem even after posting the
question on Reddit/stack overflow, so I am posting it here.

My question is as follows:

I have a static library and two target executables, let's call them
**libA**, **EXE1**, **EXE2**.

**libA** has pre-processor macros which needs to be enabled or disabled and
another static library which needs to be linked or ignored based on the
target executable that I am building.

Let's say, if I am building EXE1. Then I need to enable the macros in libA
and link another static library to it.

If I am building EXE2, I need to disabled the macros in libA and don't link
to another library.

I don't want to create two targets with same source files.

I am confused on how to solve this issue. Please kindly help in solving
this issue.
-- 

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

Re: [CMake] CMake with FetchContent instead of Git Submodules

[Dustyn Blasig]

Wow, how did I miss that when I was looking through the page yesterday?
That's exactly what I need ; )

I may try going one step further and adding a flag _USE_CLONE=ON
that will do the full checkout to a repos directory, initialize the repo to
the target tag, and then set FETCHCONTENT_SOURCE_DIR_ for the
user. The former would only be done iff the repo doesn't already exist.

On Fri, Jun 28, 2019 at 5:25 AM Craig Scott  wrote:

>
>
> On Fri, Jun 28, 2019 at 12:18 PM Dustyn Blasig  wrote:
>
>> Hi All,
>>
>> I'm attempting to replace our use of git submodules with FetchContent
>> flows instead so we can pull pre-built packages if they already exist
>> instead of buildings locally.
>>
>> However, I need to support a flow similar to Git submodules where
>> developers can edit a submodule and then rebuild the enclosing project
>> incrementally. Things seem to work OK if I jump into the fetched source
>> directories and check out branches, etc. However, even if I move the
>> download and source/unpacked folders outside the build (binary) directory
>> and then delete the build directory, rerunning CMake will blast away the
>> unpacked source even if the last extraction was with the same checksummed
>> download. I need to ensure a "clean" won't delete someones work in a
>> submodule, which is one reason why Git makes it hard to uninit and remove
>> submodules.
>>
>> Is there a best practice for a flow like this that I can replicate?
>>
>
> (Background info: I'm the creator of the FetchContent module)
>
> If you want to be making changes to the sources, you should clone that
> repo manually and point the build at it rather than try to modify the one
> that the project downloads for you. You do this by setting the
> FETCHCONTENT_SOURCE_DIR_ cache variable to override where the
> build should find the sources. Here's the relevant part from the
> FetchContent documentation:
>
> FETCHCONTENT_SOURCE_DIR_If this is set, no download or update
> steps are performed for the specified content and the _SOURCE_DIR 
> variable
> returned to the caller is pointed at this location. This gives developers a
> way to have a separate checkout of the content that they can modify freely
> without interference from the build. The build simply uses that existing
> source, but it still defines _BINARY_DIR to point inside its own
> build area. Developers are strongly encouraged to use this mechanism rather
> than editing the sources populated in the default location, as changes to
> sources in the default location can be lost when content population details
> are changed by the project.
>
> The thinking behind this is that the project will assume it is in control
> of the sources unless told otherwise. By setting the above cache variable,
> you are telling FetchContent that "I want to use my own sources instead of
> whatever you would normally use". Either FetchContent is in control or you
> are.
>
> I use this feature a LOT. Let's say you're working on a project where you
> need to do some refactoring that requires changes in the top level project
> and in some of its dependencies. I will have the top level project cloned.
> I will also have separate manually cloned repos for those dependencies that
> I need to modify. When I run CMake on my top level project, I use
> FETCHCONTENT_SOURCE_DIR_ to point the build at my local cloned
> repos. That makes the build use my local clones so I can modify the
> sources, change branches, etc. without fear of things being changed under
> my feet. When I'm done, I'll commit and push my changes in each of the
> local cloned repos, then I'll update the GIT_HASH details of those
> dependencies in my top level project. I delete the
> FETCHCONTENT_SOURCE_DIR_<...> variables from my CMake cache and re-run
> CMake (and build) to confirm that I've updated my dependency hashes
> correctly, then I commit and push my changes to the top level project.
>
> I use this strategy with project hierarchies with 40+ dependencies that
> can be up to maybe 10 levels deep. I can pull out any dependency used
> anywhere in the hierarchy and work with my own local cloned repo without
> having to care about where in the project hierarchy that dependency is
> usually populated. Being able to easily and selectively switch between the
> project-controlled FetchContent-provided source or my own local cloned
> repo(s) is critical to being able to do this efficiently. If you look at
> the CMake cache variables in ccmake or cmake-gui, you will also see all the
> source directory overrides grouped together because the variable names all
> start with FETCHCONTENT_SOURCE_DIR (this is why I named the cache variables
> FetchContent creates this way instead of putting the dependency name at the
> front of the cache variable name). So you can quickly see for which
> dependencies you are currently using a local cloned repo instead of what
> the project normally uses.
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> Get 

Re: [CMake] CMake with FetchContent instead of Git Submodules

[Craig Scott]

On Fri, Jun 28, 2019 at 12:18 PM Dustyn Blasig  wrote:

> Hi All,
>
> I'm attempting to replace our use of git submodules with FetchContent
> flows instead so we can pull pre-built packages if they already exist
> instead of buildings locally.
>
> However, I need to support a flow similar to Git submodules where
> developers can edit a submodule and then rebuild the enclosing project
> incrementally. Things seem to work OK if I jump into the fetched source
> directories and check out branches, etc. However, even if I move the
> download and source/unpacked folders outside the build (binary) directory
> and then delete the build directory, rerunning CMake will blast away the
> unpacked source even if the last extraction was with the same checksummed
> download. I need to ensure a "clean" won't delete someones work in a
> submodule, which is one reason why Git makes it hard to uninit and remove
> submodules.
>
> Is there a best practice for a flow like this that I can replicate?
>

(Background info: I'm the creator of the FetchContent module)

If you want to be making changes to the sources, you should clone that repo
manually and point the build at it rather than try to modify the one that
the project downloads for you. You do this by setting the
FETCHCONTENT_SOURCE_DIR_ cache variable to override where the
build should find the sources. Here's the relevant part from the
FetchContent documentation:

FETCHCONTENT_SOURCE_DIR_If this is set, no download or update steps
are performed for the specified content and the _SOURCE_DIR variable
returned to the caller is pointed at this location. This gives developers a
way to have a separate checkout of the content that they can modify freely
without interference from the build. The build simply uses that existing
source, but it still defines _BINARY_DIR to point inside its own
build area. Developers are strongly encouraged to use this mechanism rather
than editing the sources populated in the default location, as changes to
sources in the default location can be lost when content population details
are changed by the project.

The thinking behind this is that the project will assume it is in control
of the sources unless told otherwise. By setting the above cache variable,
you are telling FetchContent that "I want to use my own sources instead of
whatever you would normally use". Either FetchContent is in control or you
are.

I use this feature a LOT. Let's say you're working on a project where you
need to do some refactoring that requires changes in the top level project
and in some of its dependencies. I will have the top level project cloned.
I will also have separate manually cloned repos for those dependencies that
I need to modify. When I run CMake on my top level project, I use
FETCHCONTENT_SOURCE_DIR_ to point the build at my local cloned
repos. That makes the build use my local clones so I can modify the
sources, change branches, etc. without fear of things being changed under
my feet. When I'm done, I'll commit and push my changes in each of the
local cloned repos, then I'll update the GIT_HASH details of those
dependencies in my top level project. I delete the
FETCHCONTENT_SOURCE_DIR_<...> variables from my CMake cache and re-run
CMake (and build) to confirm that I've updated my dependency hashes
correctly, then I commit and push my changes to the top level project.

I use this strategy with project hierarchies with 40+ dependencies that can
be up to maybe 10 levels deep. I can pull out any dependency used anywhere
in the hierarchy and work with my own local cloned repo without having to
care about where in the project hierarchy that dependency is usually
populated. Being able to easily and selectively switch between the
project-controlled FetchContent-provided source or my own local cloned
repo(s) is critical to being able to do this efficiently. If you look at
the CMake cache variables in ccmake or cmake-gui, you will also see all the
source directory overrides grouped together because the variable names all
start with FETCHCONTENT_SOURCE_DIR (this is why I named the cache variables
FetchContent creates this way instead of putting the dependency name at the
front of the cache variable name). So you can quickly see for which
dependencies you are currently using a local cloned repo instead of what
the project normally uses.


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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide 
-- 

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 

[CMake] CMake with FetchContent instead of Git Submodules

[Dustyn Blasig]

Hi All,

I'm attempting to replace our use of git submodules with FetchContent flows
instead so we can pull pre-built packages if they already exist instead of
buildings locally.

However, I need to support a flow similar to Git submodules where
developers can edit a submodule and then rebuild the enclosing project
incrementally. Things seem to work OK if I jump into the fetched source
directories and check out branches, etc. However, even if I move the
download and source/unpacked folders outside the build (binary) directory
and then delete the build directory, rerunning CMake will blast away the
unpacked source even if the last extraction was with the same checksummed
download. I need to ensure a "clean" won't delete someones work in a
submodule, which is one reason why Git makes it hard to uninit and remove
submodules.

Is there a best practice for a flow like this that I can replicate?

Thanks!
-- 

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

Re: [CMake] cmake on MinGW64; which generator

[Ray Donnelly]

The problem is the time required to upstream such work. Unfortunately I do
not have that time.

On Tue, Jun 25, 2019, 12:15 AM Alan W. Irwin 
wrote:

> On 2019-06-24 07:39-0600 Christopher Webster wrote:
>
> > Thank you Benjamin, that [install and use mingw-w64-x86_64-cmake in the
> mingw64 shell] fixed it.
>
> I was happy to hear that Benjamin solved this first issue for you.
>
> Just to follow up on what he said, I confirm the good PLplot results
> for the MSYS2 platform that I referred to in my previous post also
> used the "mingw-w64-x86_64-cmake" native package rather than the
> non-native (linked to msys2.dll) "cmake" package.
>
> You (and others reading this thread) should consult the patches at
> 
> to see the various ways that the "mingw-w64-x86_64-cmake" package
> differs from vanilla cmake for Windows from Kitware.  I agree with
> another poster's comments that if indeed some or all of those fixes
> are really necessary for the MSYS2 platform that ideally they should
> be adopted by the upstream CMake developers.  So I hope those
> developers are (i) reading this thread and (ii) willing to follow up
> by looking at those patches.
>
> 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
> __
> --
>
> 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

Re: [CMake] cmake on MinGW64; which generator

[Alan W. Irwin]

On 2019-06-24 07:39-0600 Christopher Webster wrote:


Thank you Benjamin, that [install and use mingw-w64-x86_64-cmake in the mingw64 
shell] fixed it.


I was happy to hear that Benjamin solved this first issue for you.

Just to follow up on what he said, I confirm the good PLplot results
for the MSYS2 platform that I referred to in my previous post also
used the "mingw-w64-x86_64-cmake" native package rather than the
non-native (linked to msys2.dll) "cmake" package.

You (and others reading this thread) should consult the patches at

to see the various ways that the "mingw-w64-x86_64-cmake" package
differs from vanilla cmake for Windows from Kitware.  I agree with
another poster's comments that if indeed some or all of those fixes
are really necessary for the MSYS2 platform that ideally they should
be adopted by the upstream CMake developers.  So I hope those
developers are (i) reading this thread and (ii) willing to follow up
by looking at those patches.

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
__
--

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

Re: [CMake] cmake on MinGW64; which generator

[Volker Enderlein]

Am 24.06.2019 um 16:42 schrieb Christopher Webster:

On 6/24/19 8:03 AM, Volker Enderlein wrote:

Am 24.06.2019 um 15:39 schrieb Christopher Webster:

Hi Christopher,

did you followed the instructions from
https://bitbucket.org/Coin3D/coin/wiki/BuildWithCMake
and cloned the repo, e.g. ran hg clone
https://bitbucket.org/Coin3D/coin coin ?

As coin uses subrepositories the Download the compressed sources from
the Download section does not work. The subrepos won't be populated.

Hi Volker,

I am following the instructions at the wiki page you listed above and
used hg(1) to download.  Their example is for Visual Studio Generator.
I am wading through MinGW vs. MSYS for generator.  MinGW complains the
sh.exe is in my path and MSYS errors out with a cpack.d error.  Though I
suspect I want the MinGW.

I did get the Coin3D going on MacOS, and Quarter (though
Quarter.framework installed kind of funny, so working through that also).

Thanks,
Chris


Hi Chris,


you might also open an issue on the Coin issue tracker for that cpack.d 
problem (or for your entire build issue).


As the framework option on macOS is not very well tested I would 
recommend to use the plain ole dylib approach. That is known to work for 
Coin, SoQt, SoXt and Quarter. Recently the default setting to build a 
framework on macOS has been changed for Coin3D as it is still being 
considered experimental. You may check the last few commit messages.



Cheers, Volker


--

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

Re: [CMake] cmake on MinGW64; which generator

[Christopher Webster]

On 6/24/19 8:03 AM, Volker Enderlein wrote:
> Am 24.06.2019 um 15:39 schrieb Christopher Webster:
>
> Hi Christopher,
>
> did you followed the instructions from
> https://bitbucket.org/Coin3D/coin/wiki/BuildWithCMake
> and cloned the repo, e.g. ran hg clone
> https://bitbucket.org/Coin3D/coin coin ?
>
> As coin uses subrepositories the Download the compressed sources from
> the Download section does not work. The subrepos won't be populated.

Hi Volker,

I am following the instructions at the wiki page you listed above and
used hg(1) to download.  Their example is for Visual Studio Generator. 
I am wading through MinGW vs. MSYS for generator.  MinGW complains the
sh.exe is in my path and MSYS errors out with a cpack.d error.  Though I
suspect I want the MinGW.

I did get the Coin3D going on MacOS, and Quarter (though
Quarter.framework installed kind of funny, so working through that also).

Thanks,
Chris

-- 

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

Re: [CMake] cmake on MinGW64; which generator

[Volker Enderlein]

Am 24.06.2019 um 15:39 schrieb Christopher Webster:

Hi Christopher,

did you followed the instructions from 
https://bitbucket.org/Coin3D/coin/wiki/BuildWithCMake
and cloned the repo, e.g. ran hg clone https://bitbucket.org/Coin3D/coin 
coin ?


As coin uses subrepositories the Download the compressed sources from 
the Download section does not work. The subrepos won't be populated.


Cheers Volker

Thank you Benjamin, that fixed it.  Now to figure out the cpack.d error.

Is there a way to search the archives?  I had looked through the last
several months of threads, but that is not practical for searching back
a over a year

Chris



--

--

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

Re: [CMake] cmake on MinGW64; which generator

[Christopher Webster]

Thank you Benjamin, that fixed it.  Now to figure out the cpack.d error.

Is there a way to search the archives?  I had looked through the last
several months of threads, but that is not practical for searching back
a over a year

Chris


On 6/23/19 11:46 PM, Benjamin Eikel wrote:
> Dear Christopher,
>
> Am 23. Juni 2019 23:31:01 MESZ schrieb Christopher Webster :
>> On 6/23/19 9:22 AM, Alan W. Irwin wrote:
>>> There are a lot of different platforms that use the MinGW-w64
>> compiler
>>> so you should probably
>>> describe the platform where you are attempting to use that compiler
>> in
>>> more detail.  For example,
>>> it sounds like you are simply taking a normal Window platform and
>>> downloading the
>>> MinGW-w64 compiler for that platform, but what is the exact URL for
>>> that download?
>> As Cristian surmised we use msys2/mingw64; we download from
>> www.msys2.org (the x86_64 option).  Then install the mingw64 toolchain,
>> and use mingw64 shells:
>>
>> pacman -Sy msys2-devel
>> pacman -Sy mingw-w64-x86_64-toolchain
>> pacman -Sy base-devel
>> pacman -Sy mingw-w64-x86_64-check
>> pacman -Sy mingw-w64-x86_64-qt5
>> pacman -Sy mingw-w64-x86_64-qwt-qt5
>> pacman -Sy mingw-w64-x86_64-doxygen
>> pacman -Sy mingw-w64-x86_64-boost
>> pacman -Sy mingw-w64-x86_64-git-lfs
>> pacman -Sy mingw-w64-x86_64-gsl
>> pacman -Sy mingw-w64-x86_64-netcdf
>> pacman -Sy mingw-w64-x86_64-curl
>> pacman -Sy mingw-w64-x86_64-postgresql
>> pacman -Sy nano scons vim git procps
>>
>> cmake was installed via:
>>
>> pacman -Sy cmake
>
> try to install and use mingw-w64-x86_64-cmake in the mingw64 shell. 
> Additionally, see this answer and the corresponding thread:
> https://cmake.org/pipermail/cmake/2018-January/066869.html
>
> Kind regards
> Benjamin
>


-- 

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

Re: [CMake] cmake on MinGW64; which generator

[Benjamin Eikel]

Dear Christopher,

Am 23. Juni 2019 23:31:01 MESZ schrieb Christopher Webster :
>On 6/23/19 9:22 AM, Alan W. Irwin wrote:
>>
>> There are a lot of different platforms that use the MinGW-w64
>compiler
>> so you should probably
>> describe the platform where you are attempting to use that compiler
>in
>> more detail.  For example,
>> it sounds like you are simply taking a normal Window platform and
>> downloading the
>> MinGW-w64 compiler for that platform, but what is the exact URL for
>> that download?
>
>As Cristian surmised we use msys2/mingw64; we download from
>www.msys2.org (the x86_64 option).  Then install the mingw64 toolchain,
>and use mingw64 shells:
>
>pacman -Sy msys2-devel
>pacman -Sy mingw-w64-x86_64-toolchain
>pacman -Sy base-devel
>pacman -Sy mingw-w64-x86_64-check
>pacman -Sy mingw-w64-x86_64-qt5
>pacman -Sy mingw-w64-x86_64-qwt-qt5
>pacman -Sy mingw-w64-x86_64-doxygen
>pacman -Sy mingw-w64-x86_64-boost
>pacman -Sy mingw-w64-x86_64-git-lfs
>pacman -Sy mingw-w64-x86_64-gsl
>pacman -Sy mingw-w64-x86_64-netcdf
>pacman -Sy mingw-w64-x86_64-curl
>pacman -Sy mingw-w64-x86_64-postgresql
>pacman -Sy nano scons vim git procps
>
>cmake was installed via:
>
>pacman -Sy cmake


try to install and use mingw-w64-x86_64-cmake in the mingw64 shell. 
Additionally, see this answer and the corresponding thread:
https://cmake.org/pipermail/cmake/2018-January/066869.html

Kind regards
Benjamin

>
>
>>
>> I don't have any recent direct experience myself (I have no access to
>> Microsoft Windows and Wine Windows bugs are currently blocking access
>> to MSYS2), but PLplot developers I am aquainted with have recently
>had
>> a lot of success with the [MSYS2
>> platform](https://github.com/msys2/msys2/wiki) which is another
>exaple
>> of a platform that uses the MinGW-w64 compiler.  For that platform
>> they have found that "Unix Makefiles" and "MSYS Makefiles" generally
>> give good results.  They haven't yet tried "MinGW Makefiles" but from
>> my ancient (MSYS/Wine where MSYS is the predecessor of MSYS2)
>> experience for that generator you have to be sure that sh.exe is not
>> on your PATH (e.g., by renaming it) before it will work.  (I have
>> never quite been sure why that was a requirement, but my guess was
>the
>> "mingw" make version acts differently if it detects sh.exe.)  But
>> again from my ancient experience the rest of the Unix tools provided
>> by MSYS2 including bash.exe will likely work well with the "MinGW
>> Makefiles" generator.
>>
>> I hope this (ancient direct and recent indirect) practical experience
>> with "Unix Makefiles", "MSYS Makefiles", "MinGW Makefiles", and
>> MinGW-w64 will be of some help to you.
>>
>> 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
>> __
>
>
>-- 
>
>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

Re: [CMake] cmake on MinGW64; which generator

[Christopher Webster]

On 6/23/19 9:22 AM, Alan W. Irwin wrote:
>
> There are a lot of different platforms that use the MinGW-w64 compiler
> so you should probably
> describe the platform where you are attempting to use that compiler in
> more detail.  For example,
> it sounds like you are simply taking a normal Window platform and
> downloading the
> MinGW-w64 compiler for that platform, but what is the exact URL for
> that download?

As Cristian surmised we use msys2/mingw64; we download from
www.msys2.org (the x86_64 option).  Then install the mingw64 toolchain,
and use mingw64 shells:

pacman -Sy msys2-devel
pacman -Sy mingw-w64-x86_64-toolchain
pacman -Sy base-devel
pacman -Sy mingw-w64-x86_64-check
pacman -Sy mingw-w64-x86_64-qt5
pacman -Sy mingw-w64-x86_64-qwt-qt5
pacman -Sy mingw-w64-x86_64-doxygen
pacman -Sy mingw-w64-x86_64-boost
pacman -Sy mingw-w64-x86_64-git-lfs
pacman -Sy mingw-w64-x86_64-gsl
pacman -Sy mingw-w64-x86_64-netcdf
pacman -Sy mingw-w64-x86_64-curl
pacman -Sy mingw-w64-x86_64-postgresql
pacman -Sy nano scons vim git procps

cmake was installed via:

pacman -Sy cmake


>
> I don't have any recent direct experience myself (I have no access to
> Microsoft Windows and Wine Windows bugs are currently blocking access
> to MSYS2), but PLplot developers I am aquainted with have recently had
> a lot of success with the [MSYS2
> platform](https://github.com/msys2/msys2/wiki) which is another exaple
> of a platform that uses the MinGW-w64 compiler.  For that platform
> they have found that "Unix Makefiles" and "MSYS Makefiles" generally
> give good results.  They haven't yet tried "MinGW Makefiles" but from
> my ancient (MSYS/Wine where MSYS is the predecessor of MSYS2)
> experience for that generator you have to be sure that sh.exe is not
> on your PATH (e.g., by renaming it) before it will work.  (I have
> never quite been sure why that was a requirement, but my guess was the
> "mingw" make version acts differently if it detects sh.exe.)  But
> again from my ancient experience the rest of the Unix tools provided
> by MSYS2 including bash.exe will likely work well with the "MinGW
> Makefiles" generator.
>
> I hope this (ancient direct and recent indirect) practical experience
> with "Unix Makefiles", "MSYS Makefiles", "MinGW Makefiles", and
> MinGW-w64 will be of some help to you.
>
> 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
> __


-- 

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

Re: [CMake] cmake on MinGW64; which generator

[Alan W. Irwin]

On 2019-06-23 07:49-0600 Christopher Webster wrote:


Greetings,

  I am trying to figure out which generator to use on MinGW64 on Windows10, the 
2-3 I have tried fail.

cmake version is 3.14.5


If I try "Unix Makefiles" I get:

$ cmake -S coin -B coin_build -G "Unix Makefiles" 
-DCMAKE_INSTALL_PREFIX=C:\Tools\Packages\Coin3D
-- The C compiler identification is GNU 9.1.0
-- The CXX compiler identification is GNU 9.1.0
System is unknown to cmake, create:
Platform/MINGW64_NT-10.0-17763 to use this system, please send your
config file to cm...@www.cmake.org so it can be added to cmake



If I try "MinGW Makefiles" I get:

$ cmake -S coin -B coin_build -G "MinGW Makefiles" 
-DCMAKE_INSTALL_PREFIX=C:\Tools\Packages\Coin3D
CMake Error: Could not create named generator MinGW Makefiles



There are a lot of different platforms that use the MinGW-w64 compiler so you 
should probably
describe the platform where you are attempting to use that compiler in more 
detail.  For example,
it sounds like you are simply taking a normal Window platform and downloading 
the
MinGW-w64 compiler for that platform, but what is the exact URL for that 
download?

I don't have any recent direct experience myself (I have no access to
Microsoft Windows and Wine Windows bugs are currently blocking access
to MSYS2), but PLplot developers I am aquainted with have recently had
a lot of success with the [MSYS2
platform](https://github.com/msys2/msys2/wiki) which is another exaple
of a platform that uses the MinGW-w64 compiler.  For that platform
they have found that "Unix Makefiles" and "MSYS Makefiles" generally
give good results.  They haven't yet tried "MinGW Makefiles" but from
my ancient (MSYS/Wine where MSYS is the predecessor of MSYS2)
experience for that generator you have to be sure that sh.exe is not
on your PATH (e.g., by renaming it) before it will work.  (I have
never quite been sure why that was a requirement, but my guess was the
"mingw" make version acts differently if it detects sh.exe.)  But
again from my ancient experience the rest of the Unix tools provided
by MSYS2 including bash.exe will likely work well with the "MinGW
Makefiles" generator.

I hope this (ancient direct and recent indirect) practical experience
with "Unix Makefiles", "MSYS Makefiles", "MinGW Makefiles", and
MinGW-w64 will be of some help to you.

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
__
--

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

Re: [CMake] cmake on MinGW64; which generator

[Cristian Adam]

Hi,

You are most probably using MSys2, which means that you are using CMake
from MSys2,
and they patch CMake for their platform. This also means that CMake
upstream doesn't support it.

Here  are the differences between
upstream CMake 3.14.3 and MSys2 CMake 3.14.3. No idea why
the MSys2 people didn't try to upstream this into CMake.

In this case you should get support from MSys2 people, or switch to upstream
CMake  and standalone MinGW-w64

.

Alternatively you can try using the Ninja generator.

The problem with standalone MinGW-w64 is that you will not have the number
of libraries that MSys2 offers.
You can use a CMake package manager like Conan, or Hunter to obtain those
libraries.

I know this because when I tried to compile Qt6::Base with MSys2 I was not
able to compile, due to
various Msys2 problems. With upstream CMake, standalone MinGW-w64 and
Hunter 3rd party libraries
everything worked just fine. At https://bugreports.qt.io/browse/QTBUG-75578
I described how I compiled Qt6::Base.

Cheers,
Cristian.


On Sun, Jun 23, 2019 at 3:49 PM Christopher Webster  wrote:

> Greetings,
>
>   I am trying to figure out which generator to use on MinGW64 on Windows10, 
> the 2-3 I have tried fail.
>
> cmake version is 3.14.5
>
>
> If I try "Unix Makefiles" I get:
>
> $ cmake -S coin -B coin_build -G "Unix Makefiles" 
> -DCMAKE_INSTALL_PREFIX=C:\Tools\Packages\Coin3D
> -- The C compiler identification is GNU 9.1.0
> -- The CXX compiler identification is GNU 9.1.0
> System is unknown to cmake, create:
> Platform/MINGW64_NT-10.0-17763 to use this system, please send your
> config file to cm...@www.cmake.org so it can be added to cmake
>
>
>
> If I try "MinGW Makefiles" I get:
>
> $ cmake -S coin -B coin_build -G "MinGW Makefiles" 
> -DCMAKE_INSTALL_PREFIX=C:\Tools\Packages\Coin3D
> CMake Error: Could not create named generator MinGW Makefiles
>
> Generators
> * Unix Makefiles   = Generates standard UNIX makefiles.
>   Ninja= Generates build.ninja files.
>   CodeBlocks - Ninja   = Generates CodeBlocks project files.
>   CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
>   CodeLite - Ninja = Generates CodeLite project files.
>   CodeLite - Unix Makefiles= Generates CodeLite project files.
>   Sublime Text 2 - Ninja   = Generates Sublime Text 2 project files.
>   Sublime Text 2 - Unix Makefiles
>= Generates Sublime Text 2 project files.
>   Kate - Ninja = Generates Kate project files.
>   Kate - Unix Makefiles= Generates Kate project files.
>   Eclipse CDT4 - Ninja = Generates Eclipse CDT 4.0 project files.
>   Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files
>
>
> Thanks for any guidance.
>
> Chris
>
>
> --
>
> 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

[CMake] cmake on MinGW64; which generator

[Christopher Webster]

Greetings,

  I am trying to figure out which generator to use on MinGW64 on Windows10, the 
2-3 I have tried fail.

cmake version is 3.14.5


If I try "Unix Makefiles" I get:

$ cmake -S coin -B coin_build -G "Unix Makefiles" 
-DCMAKE_INSTALL_PREFIX=C:\Tools\Packages\Coin3D
-- The C compiler identification is GNU 9.1.0
-- The CXX compiler identification is GNU 9.1.0
System is unknown to cmake, create:
Platform/MINGW64_NT-10.0-17763 to use this system, please send your
config file to cm...@www.cmake.org so it can be added to cmake



If I try "MinGW Makefiles" I get:

$ cmake -S coin -B coin_build -G "MinGW Makefiles" 
-DCMAKE_INSTALL_PREFIX=C:\Tools\Packages\Coin3D
CMake Error: Could not create named generator MinGW Makefiles

Generators
* Unix Makefiles   = Generates standard UNIX makefiles.
  Ninja    = Generates build.ninja files.
  CodeBlocks - Ninja   = Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
  CodeLite - Ninja = Generates CodeLite project files.
  CodeLite - Unix Makefiles    = Generates CodeLite project files.
  Sublime Text 2 - Ninja   = Generates Sublime Text 2 project files.
  Sublime Text 2 - Unix Makefiles
   = Generates Sublime Text 2 project files.
  Kate - Ninja = Generates Kate project files.
  Kate - Unix Makefiles    = Generates Kate project files.
  Eclipse CDT4 - Ninja = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files


Thanks for any guidance.

Chris

-- 

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

Re: [CMake] CMake Digest, Vol 182, Issue 32

[Michael Wild]

On Wed, Jun 19, 2019 at 11:30 AM Innokentiy Alaytsev wrote:
> Hello!
>
> Are the header files of the shared library (DLL) listed as INTERFACE_SOURCES
> for the library target? AFAIK, the only reason for header files to be
> processed by AUTOMOC is to be part of the project. The only way that I know
> of for adding library headers to the consuming project is by declaring them
> as INTERFACE sources of the library target.
>
> Best regards,
> Innokentiy Alaytsev

Hi Innokentiy

Thanks, your answer gave me the hint I needed. And yes, I was being stupid :-)

Problem was that I used `target_sources( PRIVATE mywindow.cpp PUBLIC
mywindow.h )` misinterpreting what `PUBLIC` does. I figured it would
add it to the `PUBLIC_HEADER` property; I would never have imagined
that it causes the `mywindow.h` header to be added as a source to the
targets that link against the library! So, I should do some RTFM on
all the new shiny features in CMake...

Kind regards

Michael
-- 

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

[CMake] CMake now available to Linux users as a snap

[Craig Scott]

Hi all. For those of you working on Linux, I'm pleased to announce that
CMake is now available as a snap. This can be a great way to conveniently
keep up with the latest CMake releases, even on Linux distributions that
are no longer updating their own CMake packages. You can find a brief blog
post about it here:

https://crascit.com/2019/06/18/cmake-now-available-as-a-snap/

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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide 
-- 

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

Re: [CMake] CMake Release Candidate Builds Available for Ubuntu

[Andrew Fuller]

Thanks for the RCs, Kyle (and the rest of the CMake crew).

I tried 3.15~rc1 and it seems to have been built without https support 
file(DOWNLOAD https://foo/bar) gives a status "1;Unsupported protocol".  This 
is with version  3.15.0~rc1-0kitware2 amd64 running on Bionic.
Version 3.14.5-0kitware1ubuntu18.04.1 runs just fine out of the box.

Cheers,
-Andrew

From: CMake  on behalf of Kyle Edwards via CMake 

Sent: June 7, 2019 3:05 PM
To: CMake
Subject: [CMake] CMake Release Candidate Builds Available for Ubuntu

All,

I am pleased to announce that we are now offering Ubuntu builds of the
CMake release candidates, in addition to the production releases. The
first available release candidate build is 3.15.0~rc1-0kitware2.

If you would like to receive release candidate builds, follow the
instructions at https://apt.kitware.com/ to add the release candidate
repository to your installation. (Please note that the release
candidates are optional and opt-in - if you don't explicitly add the
release candidate repository, you will only receive production builds.)

In addition, starting with this release candidate, we are now offering
32-bit builds on Ubuntu. The steps for 32-bit Ubuntu are exactly the
same as 64-bit - just add the repository to your installation and
install it.

Happy coding!

Kyle
--

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
-- 

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

Re: [CMake] CMake is Converting lists to strings

[Marc CHEVRIER]

You are wrongly using the STRING(REPLACE …) command.

The right way to use it to avoid list conversion is to expand the list inside 
quotes (to preserve list items separators):

STRING (REPLACE "../" "" SIMPLE_LIST "${SIMPLE_LIST}")

Without the quotes, all list elements are concatenated in the result string 
(see documentation).

Another possibility is using LIST(TRANSFORM …):

LIST(TRANSFORM SIMPLE_LIST REPLACE « ^\\.\\./"  "")
Le 12 juin 2019 à 12:22 +0200, J Decker , a écrit :
> I know... just need to rebuild a new list... something like
>
>  set( _ALL_INCLUDES )
> foreach( INC ${ALL_INCLUDES})
>     string(REPLACE "../" "" INC ${INC})
>     LIST( APPEND _ALL_INCLUDES ${INC} )
> endforeach( INC )
> set( ALL_INCLUDES ${_ALL_INCLUDES})
>
> > On Wed, Jun 12, 2019 at 3:10 AM J Decker  wrote:
> > > I'm collecting sources and includes into a parent scope variable, and 
> > > then attempting to use that variable to reference the right sources.
> > > Sources get added to the list as ../(theirpath)/(source) so in the parent 
> > > level I can simply replace "../" with "" and then they are relative in 
> > > the right place.
> > > This works; as far as, the includes, sources and defines get all 
> > > collected into the top level, but when i try to remove the ../ the list 
> > > gets converted into a string.
> > >
> > > # Create a list of things
> > > set( SIMPLE_LIST -I../lib1/include -I../lib2/include -I../lib3/include )
> > > # set a variable using that list...
> > >   set( AMALG_COMMAND echo ${SIMPLE_LIST}  )
> > > # this outputs 
> > > COMMAND:echo;-I../lib1/include;-I../lib2/include;-I../lib3/include
> > >   message( "COMMAND:${AMALG_COMMAND}")
> > >
> > > # replace ../ with nothing
> > > STRING( REPLACE "../" "" SIMPLE_LIST ${SIMPLE_LIST} )
> > > # re-set a variable with the eventual command to run
> > >   set( AMALG_COMMAND echo ${SIMPLE_LIST}  )
> > > # this outputs COMMAND:echo;-Ilib1/include -Ilib2/include -Ilib3/include
> > >   message( "COMMAND:${AMALG_COMMAND}")
> > >
> > > When that final command actually gets run in a
> > >   add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/out.c   COMMAND 
> > > ${AMALG_COMMAND}  )
> > >
> > > Then the command is 'echo "-Ilib1/include -Ilib2/include -Ilib3/include"' 
> > > which is incorrect.
> > >
> > >
> > > I tried first LIST(JOIN) but that defiantly makes a string and doesn't 
> > > help.
> > > string(REPLACE " " ";" SIMPLE_LIST ${SIMPLE_LIST})  to try and reverse it 
> > > back to a list doesn't seem to help...
> --
>
> 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

Re: [CMake] CMake is Converting lists to strings

[J Decker]

I know... just need to rebuild a new list... something like

 set( _ALL_INCLUDES )
foreach( INC ${ALL_INCLUDES})
string(REPLACE "../" "" INC ${INC})
LIST( APPEND _ALL_INCLUDES ${INC} )
endforeach( INC )
set( ALL_INCLUDES ${_ALL_INCLUDES})

On Wed, Jun 12, 2019 at 3:10 AM J Decker  wrote:

> I'm collecting sources and includes into a parent scope variable, and then
> attempting to use that variable to reference the right sources.
> Sources get added to the list as ../(theirpath)/(source) so in the parent
> level I can simply replace "../" with "" and then they are relative in the
> right place.
> This works; as far as, the includes, sources and defines get all collected
> into the top level, but when i try to remove the ../ the list gets
> converted into a string.
>
> # Create a list of things
> set( SIMPLE_LIST -I../lib1/include -I../lib2/include -I../lib3/include )
> # set a variable using that list...
>   set( AMALG_COMMAND echo ${SIMPLE_LIST}  )
> # this outputs
> COMMAND:echo;-I../lib1/include;-I../lib2/include;-I../lib3/include
>   message( "COMMAND:${AMALG_COMMAND}")
>
> # replace ../ with nothing
> STRING( REPLACE "../" "" SIMPLE_LIST ${SIMPLE_LIST} )
> # re-set a variable with the eventual command to run
>   set( AMALG_COMMAND echo ${SIMPLE_LIST}  )
> # this outputs COMMAND:echo;-Ilib1/include -Ilib2/include -Ilib3/include
>   message( "COMMAND:${AMALG_COMMAND}")
>
> When that final command actually gets run in a
>   add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/out.c   COMMAND
> ${AMALG_COMMAND}  )
>
> Then the command is 'echo "-Ilib1/include -Ilib2/include -Ilib3/include"'
> which is incorrect.
>
>
> I tried first LIST(JOIN) but that defiantly makes a string and doesn't
> help.
> string(REPLACE " " ";" SIMPLE_LIST ${SIMPLE_LIST})  to try and reverse it
> back to a list doesn't seem to help...
>
-- 

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

[CMake] CMake is Converting lists to strings

[J Decker]

I'm collecting sources and includes into a parent scope variable, and then
attempting to use that variable to reference the right sources.
Sources get added to the list as ../(theirpath)/(source) so in the parent
level I can simply replace "../" with "" and then they are relative in the
right place.
This works; as far as, the includes, sources and defines get all collected
into the top level, but when i try to remove the ../ the list gets
converted into a string.

# Create a list of things
set( SIMPLE_LIST -I../lib1/include -I../lib2/include -I../lib3/include )
# set a variable using that list...
  set( AMALG_COMMAND echo ${SIMPLE_LIST}  )
# this outputs
COMMAND:echo;-I../lib1/include;-I../lib2/include;-I../lib3/include
  message( "COMMAND:${AMALG_COMMAND}")

# replace ../ with nothing
STRING( REPLACE "../" "" SIMPLE_LIST ${SIMPLE_LIST} )
# re-set a variable with the eventual command to run
  set( AMALG_COMMAND echo ${SIMPLE_LIST}  )
# this outputs COMMAND:echo;-Ilib1/include -Ilib2/include -Ilib3/include
  message( "COMMAND:${AMALG_COMMAND}")

When that final command actually gets run in a
  add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/out.c   COMMAND
${AMALG_COMMAND}  )

Then the command is 'echo "-Ilib1/include -Ilib2/include -Ilib3/include"'
which is incorrect.


I tried first LIST(JOIN) but that defiantly makes a string and doesn't help.
string(REPLACE " " ";" SIMPLE_LIST ${SIMPLE_LIST})  to try and reverse it
back to a list doesn't seem to help...
-- 

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

[CMake] CMake Release Candidate Builds Available for Ubuntu

[Kyle Edwards via CMake]

All,

I am pleased to announce that we are now offering Ubuntu builds of the
CMake release candidates, in addition to the production releases. The
first available release candidate build is 3.15.0~rc1-0kitware2.

If you would like to receive release candidate builds, follow the
instructions at https://apt.kitware.com/ to add the release candidate
repository to your installation. (Please note that the release
candidates are optional and opt-in - if you don't explicitly add the
release candidate repository, you will only receive production builds.)

In addition, starting with this release candidate, we are now offering
32-bit builds on Ubuntu. The steps for 32-bit Ubuntu are exactly the
same as 64-bit - just add the repository to your installation and
install it.

Happy coding!

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

Re: [CMake] CMake | CMake/CPack do not print out messages as they progress (#19343)

[Gonzalo Garramuño]

I found out the problem was an old ninja version.  I am closing the bug 
report.



El 06/06/19 a las 12:27, Brad King escribió:

GitLab

I tried CMake 3.14.5 and 3.15.0-rc1 on your example. They both behave 
the same. Running |ninja bundle| shows incremental output from cpack. 
Alternatively running |ninja -v bundle| shows |[0/1] cd ... && 
/.../bin/cpack -C Release --config /.../BundleConfig.cmake| followed 
by incremental output.


—
Reply to this email directly or view it on GitLab 
<https://gitlab.kitware.com/cmake/cmake/issues/19343#note_581122>.
You're receiving this email because of your account on 
gitlab.kitware.com. If you'd like to receive fewer emails, you can 
unsubscribe 
<https://gitlab.kitware.com/sent_notifications/0798f3ef1b2ad15fbb6587e8623f1845/unsubscribe> 
from this thread or adjust your notification settings.




-- 

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

Re: [CMake] Cmake/Cpack creates a corrupt .rpm

[Gonzalo Garramuño]

El 30/5/19 a las 22:16, Gonzalo Garramuño escribió:


El 30/5/19 a las 21:36, Zan Lynx escribió:

RPM files are not cpio. They contain a cpio. Use rpm2cpio as a filter.


Thanks for that.  Using:

rpm2cpio mrViewer-v5.0.7-Linux-64.rpm | cpio -idmv

I can extract all the contents of the archive with no errors.

However, rpm -i bails out with a cpio: read error.  I don't know what 
to try next.  I have to wonder if the pre/post install scripts are the 
problem.


Okay.  I found the root of the problem in the OS I was trying the RPM.  
Fedora 30 has the problem installing.  CentOS 7, for example, works just 
fine.   Not sure what has changed in Fedora (or if it ever worked on 
it).  Can someone confirm that their cmake .rpm's work in Fedora 30 
(thus, throwing my assumption out of the water)?


Thanks in advance.

--
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

Re: [CMake] Cmake/Cpack creates a corrupt .rpm

[Gonzalo Garramuño]

El 30/5/19 a las 21:36, Zan Lynx escribió:

RPM files are not cpio. They contain a cpio. Use rpm2cpio as a filter.


Thanks for that.  Using:

rpm2cpio mrViewer-v5.0.7-Linux-64.rpm | cpio -idmv

I can extract all the contents of the archive with no errors.

However, rpm -i bails out with a cpio: read error.  I don't know what to 
try next.  I have to wonder if the pre/post install scripts are the problem.


--

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

Re: [CMake] Cmake/Cpack creates a corrupt .rpm

[Zan Lynx]

On May 30, 2019 5:21:59 PM MST, "Gonzalo Garramuño"  wrote:
>
>El 30/5/19 a las 12:51, Gonzalo Garramuño escribió:
>> rpm -ql mrViewer-v5.0.6-Linux-64.rpm
>
>If I run cpio -i < mrViewer-v5.0.6-Linux-64.rpm
>
>I get a bunch of warnings of Incorrect numbers (and garbage) and Cannot
>
>make mknod: the multibyte or extended character is incomplete or 
>invalid, and attention: 4390 bytes of garbage skipped and header is 
>reversed and type of archive unknown and premature end of the archive.

RPM files are not cpio. They contain a cpio. Use rpm2cpio as a filter.
-- 
Knowledge is Power -- Power Corrupts
Study Hard -- Be Evil
-- 

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

Re: [CMake] Cmake/Cpack creates a corrupt .rpm

[Gonzalo Garramuño]

El 30/5/19 a las 12:51, Gonzalo Garramuño escribió:

rpm -ql mrViewer-v5.0.6-Linux-64.rpm


If I run cpio -i < mrViewer-v5.0.6-Linux-64.rpm

I get a bunch of warnings of Incorrect numbers (and garbage) and Cannot 
make mknod: the multibyte or extended character is incomplete or 
invalid, and attention: 4390 bytes of garbage skipped and header is 
reversed and type of archive unknown and premature end of the archive.


--
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

Re: [CMake] cmake rewrites part of -S argument depending on the current directory!

[Brad King via CMake]

On 5/30/19 1:25 PM, Marc Herbert wrote:
> I suspect the behaviour I described is also considered a bug

Yes, it is a bug and is related to 16228.  The problem is that
there is a poor implementation of support for the use case
described in that issue, and the details of that implementation
leak out in other use cases.

Ben (in Cc) has a plan to resolve the problem but hasn't had
time to implement it yet.

-Brad
-- 

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

Re: [CMake] cmake rewrites part of -S argument depending on the current directory!

[Marc Herbert]

Thanks Brad for the reference, really appreciated. Some of 16228 seems
relevant. Other parts unfortunately not because 16228:
- tries to deal with all the crazy ways users can use symbolic links,
including relative paths and relative links,
- tries to deal with all the ways users can invoke cmake,
- naturally cares about backward compatibility,
- goes deep into the implementation details,
- refers to other issues with even more implementation details.

So I'm admittedly getting lost in all the details and combinatorial
explosion. Because 16228 looks like a bug I suspect the behaviour I
described is also considered a bug but I'm not even sure?

I believe the example I gave is one of the simplest and safest use cases of
symbolic links that : passing both -B and -S, no relative path, no relative
link. For such a "most explicit" use case, will future cmake versions be
unaffected by the current directory?

-B is a brand new option so there's only so much backward compatibility it
has to care about, right?

Long story short I think this admittedly complex topic could use some high
level documentation or - if the symlink situation is hopelessly complicated
and everything fails - at least a big "AVOID SYMLINKS [FOR NOW]" warning
somewhere in the documentation. Fair enough? Sorry if I missed that.

Thanks!

Marc


Le jeu. 30 mai 2019 à 07:15, Brad King  a écrit :

> On 5/30/19 3:22 AM, Marc Herbert wrote:
> > IF the current directory is a parent of the -S argument AND
> > one component of the current directory is a symbolic link THEN
> > the leading part of the -S argument is overridden using that
> > symbolic link.
>
> See this issue:
>
>   https://gitlab.kitware.com/cmake/cmake/issues/16228
>
> -Brad
>
-- 

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

Re: [CMake] Cmake/Cpack creates a corrupt .rpm

[Gonzalo Garramuño]

El 30/5/19 a las 12:51, Gonzalo Garramuño escribió:

I have a CMakeLists.txt (extract) with the following commands:


SET(CPACK_GENERATOR DEB RPM TGZ )

# SET the installation directory.

SET(CPACK_SET_DESTDIR true) # Needed
SET(CPACK_INSTALL_PREFIX /usr/local/${mrViewerShortName})

SET(CPACK_RPM_PACKAGE_NAME mrViewer)
SET(CPACK_RPM_PACKAGE_RELOCATABLE false)


SET(  CPACK_RPM_POST_INSTALL_SCRIPT_FILE
    ${PROJECT_BINARY_DIR}/etc/Linux/install.sh)
SET( CPACK_RPM_POST_UNINSTALL_SCRIPT_FILE
    ${PROJECT_BINARY_DIR}/etc/Linux/uninstall.sh)


  SET(CPACK_PACKAGE_VENDOR "Film Aura, LLC")
  SET(CPACK_PACKAGE_VERSION_MAJOR ${VersionMajor})
  SET(CPACK_PACKAGE_VERSION_MINOR ${VersionMinor})
  SET(CPACK_PACKAGE_VERSION_PATCH ${VersionPatch})
  SET(CPACK_PACKAGE_VERSION "${SHORTVERSION}" )
  SET(CPACK_PACKAGE_FILE_NAME "${mrViewerPackageName}" )
  SET(CPACK_PACKAGE_CONTACT "ggarr...@gmail.com")
  SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY
      "mrViewer provides professional flipbook, audio and video 
playback.")



#SET(CPACK_PACKAGE_INSTALL_REGISTRY_KEY ${mrViewerPackageName} )
SET(CPACK_RESOURCE_FILE_LICENSE 
${PROJECT_SOURCE_DIR}/../../docs/LICENSE.txt)


SET( CPACK_OUTPUT_CONFIG_FILE "${CMAKE_BINARY_DIR}/BundleConfig.cmake" )
include(CPack)

ADD_CUSTOM_TARGET( bundle
               COMMAND "${CMAKE_CPACK_COMMAND}"
               "-C" "$"
               "--config" "${CMAKE_BINARY_DIR}/BundleConfig.cmake"
               COMMENT "Running CPack. Please wait..."
               USES_TERMINAL
               DEPENDS translations )

This creates a valid DEB file but an invalid RPM which fails with:

Running transaction
Preparing : 1/1
Running scriptlet: mrViewer-5.0.5.20190517-1.x86_64 1/1
Installing : mrViewer-5.0.5.20190517-1.x86_64 1/1
Error unpacking rpm package mrViewer-5.0.5.20190517-1.x86_64
error: unpacking of archive failed: cpio: read

Verifying : mrViewer-5.0.5.20190517-1.x86_64 1/1

Failed:
mrViewer-5.0.5.20190517-1.x86_64

Error: Transaction failed


You can find the RPM file here:

https://sourceforge.net/projects/mrviewer/files/v5.0.6/mrViewer-v5.0.6-Linux-64.rpm/download 



If I use:

rpm -ql mrViewer-v5.0.6-Linux-64.rpm

all files are there.  However, when installing, the installer fails on 
reaching the lib directory of the rpm.


CMake/CPack used to build the rpm just fine some (long) versions ago 
with this same CMakeLists.txt.



Forgot to mention, I am using cmake 3.14.1.

--
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

[CMake] Cmake/Cpack creates a corrupt .rpm

[Gonzalo Garramuño]

I have a CMakeLists.txt (extract) with the following commands:


SET(CPACK_GENERATOR DEB RPM TGZ )

# SET the installation directory.

SET(CPACK_SET_DESTDIR true) # Needed
SET(CPACK_INSTALL_PREFIX /usr/local/${mrViewerShortName})

SET(CPACK_RPM_PACKAGE_NAME mrViewer)
SET(CPACK_RPM_PACKAGE_RELOCATABLE false)


SET(  CPACK_RPM_POST_INSTALL_SCRIPT_FILE
    ${PROJECT_BINARY_DIR}/etc/Linux/install.sh)
SET( CPACK_RPM_POST_UNINSTALL_SCRIPT_FILE
    ${PROJECT_BINARY_DIR}/etc/Linux/uninstall.sh)


  SET(CPACK_PACKAGE_VENDOR "Film Aura, LLC")
  SET(CPACK_PACKAGE_VERSION_MAJOR ${VersionMajor})
  SET(CPACK_PACKAGE_VERSION_MINOR ${VersionMinor})
  SET(CPACK_PACKAGE_VERSION_PATCH ${VersionPatch})
  SET(CPACK_PACKAGE_VERSION "${SHORTVERSION}" )
  SET(CPACK_PACKAGE_FILE_NAME "${mrViewerPackageName}" )
  SET(CPACK_PACKAGE_CONTACT "ggarr...@gmail.com")
  SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY
      "mrViewer provides professional flipbook, audio and video playback.")


#SET(CPACK_PACKAGE_INSTALL_REGISTRY_KEY ${mrViewerPackageName} )
SET(CPACK_RESOURCE_FILE_LICENSE 
${PROJECT_SOURCE_DIR}/../../docs/LICENSE.txt)


SET( CPACK_OUTPUT_CONFIG_FILE "${CMAKE_BINARY_DIR}/BundleConfig.cmake" )
include(CPack)

ADD_CUSTOM_TARGET( bundle
               COMMAND "${CMAKE_CPACK_COMMAND}"
               "-C" "$"
               "--config" "${CMAKE_BINARY_DIR}/BundleConfig.cmake"
               COMMENT "Running CPack. Please wait..."
               USES_TERMINAL
               DEPENDS translations )

This creates a valid DEB file but an invalid RPM which fails with:

Running transaction
Preparing : 1/1
Running scriptlet: mrViewer-5.0.5.20190517-1.x86_64 1/1
Installing : mrViewer-5.0.5.20190517-1.x86_64 1/1
Error unpacking rpm package mrViewer-5.0.5.20190517-1.x86_64
error: unpacking of archive failed: cpio: read

Verifying : mrViewer-5.0.5.20190517-1.x86_64 1/1

Failed:
mrViewer-5.0.5.20190517-1.x86_64

Error: Transaction failed


You can find the RPM file here:

https://sourceforge.net/projects/mrviewer/files/v5.0.6/mrViewer-v5.0.6-Linux-64.rpm/download

If I use:

rpm -ql mrViewer-v5.0.6-Linux-64.rpm

all files are there.  However, when installing, the installer fails on 
reaching the lib directory of the rpm.


CMake/CPack used to build the rpm just fine some (long) versions ago 
with this same CMakeLists.txt.



--
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

[CMake] CMake install doesn't find binary that CMake built?

[Benjamin Shadwick]

Using CMake 3.12.2.

Consider the following project:

project(myproject)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
set(CMAKE_INSTALL_PREFIX "${CMAKE_BINARY_DIR}" CACHE PATH "" FORCE)
add_executable(myprog hello.cpp)
install(TARGETS myprog
   ARCHIVE DESTINATION lib
   LIBRARY DESTINATION lib
   RUNTIME DESTINATION bin)

'make install' builds 'myprog', then it disappears, then CMake reports an
error that it cannot find it ("file INSTALL cannot find
"path_to_build_directory/bin/myprog"").

Seems like a bug/oversight. Possibly CMake is trying to move the file to
where it already exists, destroying it in the process.

And since someone will be horrified at what I'm doing with paths, the
reason is that I've got subprojects that generate hundreds of libraries and
multiple executables, and I'd like to avoid both of the following:
- Forcing developers to run 'make install' instead of 'make' before they
can run
- Setting up massive PATH and LD_LIBRARY_PATH variables so that everything
can be found when it's scattered all over the build tree

I suppose my current setup will work fine as long as nobody uses 'make
install', but I was hoping to leverage that to help with release packaging.
-- 

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