Re: [CMake] Need suggestions for implementation of new feature in cmake.

[Hendrik Sattler]

Hi Carlo,

The answer is already right in front of you: "a && b" executes b only if a 
returns positive (zero exit code). This is already done for the mkdir.

And to answer the other question: no, you cannot assume a POSIX shell in a 
Makefile.

HS


Am 27. März 2020 05:53:39 MEZ schrieb Carlo Wood :
>Hello!
>
>I'm writing a patch for cmake to address
>https://gitlab.kitware.com/cmake/cmake/issues/19703
>
>but I need a little help; I'm only familiar with
>GNU/Linux and single target generator Makefile.
>
>In terms of a Makefile, if one uses ExternalProject_Add_Step, see
>
>https://cmake.org/cmake/help/latest/module/ExternalProject.html#explicit-step-management
>
>then something like this is generated:
>
>/path/to/stamp_dir/myname-mystep: /path/to/some/dependency
>@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) \
>--blue --bold \
>--progress-dir=/path/to/buildir/CMakeFiles \
>--progress-num=$(CMAKE_PROGRESS_9) "My Comment"
>cd /path/to/workingdir && \
>my_COMMAND my_arg1 my_arg2 ... \
>cd /path/to/workingdir && \
>cmake -E touch /path/to/stamp_dir/myname-mystep
>
>Now, I'm not sure about the portability of the COMMAND that
>is passed to ExternalProject_Add_Step. Are we assuming that
>every operating system supports a POSIX (unix) shell, like bash?
>
>Otherwise it seems that the only way to be portable is to run
>cmake in script mode there.
>
>Note how the last command does this: it runs cmake in order to portably
>'touch' the target file (a stamp file).
>
>What I need is way to generate a rule where depending on a
>condition (to be decided by the COMMAND (my_COMMAND)) that
>touch is or is not done.
>
>In the single target target POSIX Makefile case this could look like
>this (I'm leaving out the COMMENT here for brevity),
>
> /path/to/stamp_dir/myname-mystep: /path/to/some/dependency
>(cd /path/to/workingdir && \
>if my_COMMAND my_arg1 my_arg2 ...; then \
>  cmake -E touch /path/to/stamp_dir/myname-mystep; \
>fi)
>
>which uses the return value of my_COMMAND to decide whether or
>not to touch the stamp file.
>
>However, this is pure shell coding: using a '(' to open a sub shell
>and then using 'if ...; then ... fi'.
>
>I'm looking for ideas on how to implement this in a portable way.
>
>How can I extract a boolean from a user defined COMMAND and then
>use that to conditionally execute the touch?
-- 

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] crosscompilation and source generation via add_custom_command

[Hendrik Sattler]

Am 3. Februar 2020 20:48:50 MEZ schrieb "Jędrzej Dudkiewicz" 
:
>Hello,
>
>I cross-compile a project from x86_64-linux-gnu to
>arm-linux-gnueabihf. Currently this is done using hand-written
>Makefiles, but I"m moving it to cmake. This project uses custom
>version of `lemon` parser generator. Aforementioned lemon is included
>as a source - this is single .c file that is compiled during build. Is
>there a way to build and run this binary on x86_64-linux-gnu while
>cross-compiling to arm-linux-gnuabihf? I suppose I could
>add_custom_command that would compile using hardcoded compiler
>version, but it doesn't seem very nice.

You can compile the tool using ExternalProject. This needs a separate directory 
with a its own CMakeLists.txt file for the tool.

>Thanks in advance,
>-- 
>Jędrzej Dudkiewicz
>
>I really hate this damn machine, I wish that they would sell it.
>It never does just what I want, but only what I tell it.
>-- 
>
>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
-- 

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 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] Embedded build using ExternalProject

[Hendrik Sattler]

Am 26. Juni 2019 15:53:16 MESZ schrieb Torsten Robitzki :
>Hello,
>
>I have a project, where binaries are build for an embedded platform and
>for a PC platform. To build software update packages for the embedded
>platforms (files that can be used to make in the field firmware
>updates), tools that have to run during the build have to be build from
>source first. For example firmware.tfp have to be build by running
>create_package with firmware.bin. firmware.bin have to build with
>settings for the embedded platform and create_package have to be build
>with setting of the build host.
>
>I’ve asked this question already a year or so ago and got the response,
>that using super builds will help me. Now I try to convert the project
>to a super build structure. Fortunately, there was very little content
>inside my main CMakeLists.txt, mainly `add_subdirectory( source )`.
>Mainly, I want to build different sets of artifacts from the same
>source tree, but with different
>
>Now I’m stuck with a number of issues. First, I want to build all
>firmware binaries for the NRF52 embedded platform:
>
>ExternalProject_Add(firmware_binaries
>SOURCE_DIR  ${CMAKE_CURRENT_LIST_DIR}/source
>INSTALL_DIR ${installDir}
>CMAKE_ARGS
>-DCMAKE_INSTALL_PREFIX:PATH=
>-DBOOTLOADER_AES_KEY=${BOOTLOADER_AES_KEY}
>-DBOOTLOADER_VERSION=${BOOTLOADER_VERSION}
>-DBUILD_DEBUG=1
>-DBUILD_NRF52=1
>BUILD_COMMAND ${CMAKE_COMMAND} --build ${CMAKE_CURRENT_BINARY_DIR}
>--target firmware_binaries
>)

The build command is using the wrong directory.

>I don’t want to build any EOL test firmware, test-tools etc. just the
>stuff that will be shipped, thus the explicit target. I can build the
>firmware_binaries, from the source directly, without problems. But when
>I try to build with the top-level cmake file, that contains the
>ExternalProject_Add(), I get the usual configure output and then:
>
>-- Configuring done
>-- Generating done
>-- Build files have been written to:
>/Users/todi/blueswd_firmware/build/firmware_binaries-prefix/src/firmware_binaries-build
>[ 75%] Performing build step for 'firmware_binaries'
>[ 12%] Performing build step for 'firmware_binaries'
>[ 12%] Performing build step for 'firmware_binaries'
>[ 12%] Performing build step for ‚firmware_binaries‘
>…
>
>This line repeats until make reports:
>
>make[776]: /usr/local/Cellar/cmake/3.14.3/bin/cmake: Resource
>temporarily unavailable
>make[776]: *** wait: No child processes.  Stop.
>make[776]: *** Waiting for unfinished jobs
>make[776]: *** wait: No child processes.  Stop.
>
>Any idea, what might be wrong here? Some kind of recursion?
>
>An other issue: I want to forward targets to the super build, so that I
>can build them there. For example I have ~30 unit test programs and
>when I’m working in a certain area, I usually want to build exactly one
>of this programs. Is it possible to export them as targets of the super
>build?
>
>A third issue that I have is, that changes to the CMakeLists.txt files
>in the Project are not reflected by the super build. If I make a change
>to one of the CMake files under ${CMAKE_CURRENT_LIST_DIR}/source, I
>usually have to delete the whole build folder and start from scratch
>with the build. Is there an other way to force the super build to
>recognize the changes? (Note: ${CMAKE_CURRENT_LIST_DIR}/source is not
>added as subdirectory to the top level (super build) CMakeLists.txt).
>
>best regards,
>
>Torsten
>
>P.S.:
>$ cmake --version
>cmake version 3.14.3
-- 

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] question ? [cmake could not find a include_dir]

[Hendrik Sattler]

How about using the same build directory?


Am 22. Mai 2019 18:02:28 MESZ schrieb "Agata Krasoń" :
>Hello,
>
>I am trying to build from source an application.
>I add in cmake-gui : XIOT_INCLUDE_DIR - path do include dir
>When I compile on linux ...
>It gives me an error:
>
>[image: Screenshot_20190522_175230.png]
>[image: Screenshot_20190522_175209.png]
>
>Do you have any idea ?
>What could be a problem?
>
>I would appreciate for any help.
>
>Best,
>Agata
-- 

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 GUI "Stop" button does not halt exec_process

[Hendrik Sattler]

Hi,

killing everything might be problematic in some cases: MSVC uses some shared 
processes to write PDB files. Killing that will make an unrelated other build 
fail. That was real fun to find out when Jenkins was cleaning up. So kill your 
children but don't be too pedantic.

HS


Am 11. Januar 2019 10:43:05 MEZ schrieb Chris Wilson :
>In case it helps, Box Backup uses Windows Job Objects
>
>to
>ensure that any daemons started during a test will automatically be
>killed
>when the test process exits (if not stopped cleanly beforehand):
>
>https://github.com/boxbackup/boxbackup/blob/s3_support/infrastructure/buildenv-testmain-template.cpp#L367
>
>On Linux you can use prctl(PR_SET_PDEATHSIG, SIGKILL) in the child
>process
>(between fork() and exec()) to achieve this.
>
>On Thu, 10 Jan 2019 at 22:17, Person Withhats
>
>wrote:
>
>> Pressing "STOP" in the CMake GUI interface halts CMake itself but
>does not
>> stop any execute_process that is going on at the time. This makes it
>hang
>> until the process finishes, since no interrupt is sent..
>>
>> Aggravating when you're using an exterior script (e.g. a .exe or .py)
>that
>> e.g. handles package maintenance. Would hang up for the entire
>duration of
>> ~40 minutes unless you force kill that sub process.
>>
>> I think force-killing CMake GUI also won't forward the kill to the
>> exec_process, orphaning it.>.<
>>
>> Let me know any suggestions or possible fixes
>> --
>>
>> 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] [ANNOUNCE] CMake 3.13.0-rc1 is ready for testing

[Hendrik Sattler]

Zitat von Robert Maynard :

* The "BundleUtilities" module may no longer be included at
  configure time. This was always a bug anyway. See policy "CMP0080".


This now warns about the use of DeployQt4.cmake that ships with CMake.
So this module should be fixed?
At least it should set this policy to OLD for itself to avoid warnings  
for users that cannot change anything about it -> annoying.


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] LOCATION target property, generator expressions

[Hendrik Sattler]

Hi,

You can use the following cmake snippet right below the project()  
command to add proper RPATH values:

  include ( GNUInstallDirs )
  if ( CMAKE_SYSTEM_NAME STREQUAL "Linux" )
list ( APPEND CMAKE_INSTALL_RPATH "\$ORIGIN/../${CMAKE_INSTALL_LIBDIR}" )
  endif ( CMAKE_SYSTEM_NAME STREQUAL "Linux" )
  set ( CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE )

This assumes, libraries are installed to CMAKE_INSTALL_LIBDIR and  
programs to CMAKE_INSTALL_BINDIR.
Additionally you may add the following line to disable a change in the  
binary files during install target run:

  set ( CMAKE_BUILD_WITH_INSTALL_RPATH ON )


The latter might be useful when splitting of debug symbols on ELF  
platforms in post-build. However, it disables running the binaries in  
the build tree.



CMake supports PDB files but split dbgsym file are (strangely) not  
supported out-of-the-box.


HS


Zitat von Hendrik Greving :


By the way, the new generator expression support in 3.13, is this for
LINK_FLAGS or LINK_OPTIONS. And regardless of the former, will it be
possible to compute a relative path based on generator expressions, i.e.
file(RELATIVE $ $)?

On Thu, Sep 27, 2018 at 5:03 PM Hendrik Greving <
hendrik.greving@gmail.com> wrote:


Thanks. Ok one step back. What we want is to have the same relative path
from binary/executable to linked library in build and install tree (which
we assume is the same for us). Looks like by default, e.g. cmake 3.9, puts
in an absolute path. The current (c-)makefiles compute the relative part of
an executable -> library by using LOCATION and add this to
-Wl,-rpath=$ORIGIN/[relative part]. We want to do the same w/o LOCATION
(i.e. resolving CMP0026)

On Thu, Sep 27, 2018 at 7:29 AM Brad King  wrote:


On 09/26/2018 10:23 AM, Hendrik Greving wrote:
> Is there any way before 3.13 to achieve what I need? Right now we
> modify LINK_FLAGS based on something that is computed with values
> from LOCATION.
[snip]
> our cmake setup is using LOCATION property for two targets to compute
> a relative path from these two, and adds this to LINK_FLAGS
> (for rpath, but irrelevant in this context).

To at least see if 3.13 will support your use case, you could
try a nightly binary from here:

  https://cmake.org/files/dev/?C=M;O=D

Use `$/..` to refer to a path relative
to the target file location.

I've never seen a need to adjust link flags based on the target
location.  CMake has several features for RPATH support.  What
are you really trying to do?

-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 accessibility, or the lack of it with latest updtes

[Hendrik Sattler]

Maybe it's related to this blog entry: 
http://blog.qt.io/blog/2018/02/20/qt-5-11-brings-new-accessibility-backend-windows/


Am 23. September 2018 17:37:21 MESZ schrieb Robert Maynard 
:
>Hi Jaffar,
>
>CMake is still using Qt for the GUI, but we have moved from Qt4 to Qt5.
>If
>you are able to tell me the explicit version of the GUI that last
>worked
>for you that will help track down what is causing this regression.
>
>On Fri, Sep 21, 2018 at 3:30 PM Jaffar Sidek 
>wrote:
>
>>  HI.  I am a blind software developer very
>dependent
>> on CMake for my development work.  I have noticed that since version
>> 3.1X, the gui version of CMake is no longer accessible.  Let me
>> clarify.  I use a screen reader for voice output in order for me to
>be
>> able to use the computer independently.  In the earlier versions of
>> CMake, My screen reader could access a large part of the interface of
>> CMake to enable me to use the program Quickly and efficiently.  But
>> since version 3.1X and the latest version 3.2X, I have had to revert
>to
>> using the command line.  I noticed that the earlier versions were
>coded
>> with QT, is that not the case anymore?  QT5 has added accessibility
>> these days, and I would appreciate it if the accessibility features
>of
>> earlier versions of CMake could be re-implemented.  Thanks and
>cheers!
>>
>> --
>>
>> 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 3.12 and changes in Visual Studio

[Hendrik Sattler]

Zitat von Hendrik Sattler :

Hi,

in CMake <= 3.11, the CMakeLists.txt file that contains the  
target-creating call, e.g. add_library(), was automatically added to  
the target as visible file in the Solution Explorer.


With CMake 3.12, this is suddenly not the case anymore.
Anybody knows what happened? On purpose or on accident?


They can be found at in _autogen projects :-/
Something went wrong in CMake 3.12, I'll file a bug report.

Regards,

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

[CMake] CMake 3.12 and changes in Visual Studio

[Hendrik Sattler]

Hi,

in CMake <= 3.11, the CMakeLists.txt file that contains the  
target-creating call, e.g. add_library(), was automatically added to  
the target as visible file in the Solution Explorer.


With CMake 3.12, this is suddenly not the case anymore.
Anybody knows what happened? On purpose or on accident?

Regards,

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] Why does CMake 3.9.0 open VS2017 when targeting 2013 after installing 2017... sigh.

[Hendrik Sattler]

Am 15. August 2018 17:45:46 MESZ schrieb Brian Davis :
>Can CMake defer to what the user ultimately wants? .. say the correct
>version of VS.  I mean that is what I thought I specified.

Do you actually read the answers?
You can configure that in the Windows explorer like it you wanted to open the 
.sln file from there. Visual Studio install the right tool.
-- 

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] Why does CMake 3.9.0 open VS2017 when targeting 2013 after installing 2017... sigh.

[Hendrik Sattler]

Am 15. August 2018 00:20:37 MESZ schrieb Brian Davis :
>Why does CMake 3.9.0 open VS2017 when targeting 2013 after installing
>2017... sigh.
>
>Without even regenerating or re configuring (even though that has no
>effect
>either) when "Open Project" is selected 2017 is opened and not 2013...
>errr
>what am I targeting again?  Happened after 2017 install.  How does
>CMake
>Decide which app to call err I got a sneaky suspicion as to how
>in
>a not so goodly way.
>
>Sure wishI could get CMake to open VS2013 with the environment vars I
>ahve
>set when it was called... guess  I'll have to settle for the new and
>improved VS2017 I can't use on the project.

Or probably uses the Qt function to open the project file with the same program 
that is configured in Explorer. So change it there. There is a Visual Studio 
version selector but VS2017 can also open some older versions and use their 
toolkits.

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] Printing "Found ..." message in config mode

[Hendrik Sattler]

Am 14. August 2018 22:08:36 MESZ schrieb "Sebastián Mancilla" 
:
>Normally, find modules call FIND_PACKAGE_HANDLE_STANDARD_ARGS, which in
>turn calls FIND_PACKAGE_MESSAGE, to print a nice message about the
>location
>and version of the dependency.

You can do that with FIND_PACKAGE_HANDLE_STANDARD_ARGS, just use module name 
and CONFIG_MODE as arguments.

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] How to build fully correctly versioned shared object files with cmake

[Hendrik Sattler]

Am 6. August 2018 22:29:21 MESZ schrieb Alexander Neundorf :
>On 2018 M08 6, Mon 21:54:33 CEST Hendrik Sattler wrote:
>> Am 6. August 2018 20:27:23 MESZ schrieb Philip Van Hoof 
>:
>> >Hello everyone,
>> >
>> >I noticed that it sometimes happens that I find a package for a
>shared
>> >object file(s) (or DLLs, on platforms like Windows) that have a
>build
>> >set up using cmake, that doesn't set everything that should be set.
>> >
>> >Usually as packagers of various popular open source softwares
>correct
>> >enthusiasts' attempts at understanding the sometimes bizarre
>> >complexities of for example autotools, but (although it's all less
>> >complicated) also cmake, it ends up somewhat right. Somewhat. I
>noticed
>> >that especially in corporate world, things tend to go spectacularly
>> >wrong. Almost without exception.
>> >
>> >In particular am I concerned about ABI versioning of shared object
>> >files so that they are easy to package and distribute by various
>> >operating systems (like, among others, Linux distributions). But
>also
>> >API versioning of development files (compiler header files and pkg-
>> >config) and installing to the right installation paths.
>> >
>> >I wanted to invite the community to scrutinize some equivalent
>examples
>> >that I made for autotools (with libtool), qmake, cmake and meson.
>> >
>> >https://github.com/pvanhoof/dir-examples/
>> >
>> >In particular I wanted to invite the cmake community to take a look
>at
>> >this example:
>> >
>> >https://github.com/pvanhoof/dir-examples/tree/master/cmake-example
>> >
>> >The idea is that the examples are as correct as possible. That means
>> >the examples should simple and educational. Easing (some amount) of
>> >platform independence (ie. supporting Windows) and packaging.
>> 
>> Is there ANY reason to use libtool library versioning? It might
>surprise
>> people but it really is not any kind of standard.
>> 
>> Just change the SOVERSION when you make incompatible ABI changes and
>a
>> normal library VERSION. There's really not more to it, especially
>nothing
>> like the sick results that libtool produces, sometimes.
>
>I agree.
>I would recommend
>Major version  = SO version, increase it if you break ABI compatibility
>Minor version: increase it if you add ABI compatible features
>Patch version: increase it for bug fix releases.

Right. See http://semver.org

A  tool to check is e.g. the abi compliance checker.

It may be worth to mention that project version and library version may differ 
but that it also might confuse people.


-- 

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] How to build fully correctly versioned shared object files with cmake

[Hendrik Sattler]

Am 6. August 2018 20:27:23 MESZ schrieb Philip Van Hoof :
>Hello everyone,
>
>I noticed that it sometimes happens that I find a package for a shared
>object file(s) (or DLLs, on platforms like Windows) that have a build
>set up using cmake, that doesn't set everything that should be set.
>
>Usually as packagers of various popular open source softwares correct
>enthusiasts' attempts at understanding the sometimes bizarre
>complexities of for example autotools, but (although it's all less
>complicated) also cmake, it ends up somewhat right. Somewhat. I noticed
>that especially in corporate world, things tend to go spectacularly
>wrong. Almost without exception.
>
>In particular am I concerned about ABI versioning of shared object
>files so that they are easy to package and distribute by various
>operating systems (like, among others, Linux distributions). But also
>API versioning of development files (compiler header files and pkg-
>config) and installing to the right installation paths.
>
>I wanted to invite the community to scrutinize some equivalent examples
>that I made for autotools (with libtool), qmake, cmake and meson.
>
>https://github.com/pvanhoof/dir-examples/
>
>In particular I wanted to invite the cmake community to take a look at
>this example:
>
>https://github.com/pvanhoof/dir-examples/tree/master/cmake-example
>
>The idea is that the examples are as correct as possible. That means
>the examples should simple and educational. Easing (some amount) of
>platform independence (ie. supporting Windows) and packaging.

Is there ANY reason to use libtool library versioning? It might surprise people 
but it really is not any kind of standard.

Just change the SOVERSION when you make incompatible ABI changes and a normal 
library VERSION. There's really not more to it, especially nothing like the 
sick results that libtool produces, sometimes.

The difficult thing is to realize the need for such a change. But there are 
tools that can help.

>ps. I don't think CC-ing a huge amount of mailing lists is necessarily
>a good idea. So feel free to forward to the appropriate people.
>
>ps. I attached no license to the examples yet. Perhaps I should attach
>one? My goal would be that as much entities could copy and use it.
>Including for, indeed, non-free purposes (as much as they want).
>
>
>Kind regards,
>
>Philip Van Hoof
-- 

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] specifying path for license file for commercial compiler?

[Hendrik Sattler]

You  could user "cmake -E env " in combination with 
https://cmake.org/cmake/help/v3.12/prop_gbl/RULE_LAUNCH_COMPILE.html and maybe 
https://cmake.org/cmake/help/v3.12/prop_gbl/RULE_LAUNCH_LINK.html if needed.


Am 6. Juli 2018 22:34:04 MESZ schrieb "Clune, Thomas L. (GSFC-6101)" 
:
>To use the Intel compiler, one must use an environment variable that
>specifies the path to the license file.  E.g.,
>
>export INTEL_LICENSE_FILE=/usr/local/intel/license
>
>Other commercial compilers use a very similar mechanism.I had hoped
>to capture such information in a cache file so that I could avoid
>polluting the shell where I am invoking cmake:
>
>% cmake -C my-cache 
>
>Such a cache file could  look like:
>
>set(CMAKE_Fortran_COMPILER
>"/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort"
>CACHE path "Fortran compiler")
>set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license" CACHE path
>"Intel license")
>
>
>Unfortunately, the compiler is not “seeing” the env variable and
>complains that there is no license. Is there a solution to this, or
>am I forced to set the env variable each time I try to build?
>
>
>
>
>
>
>
>-- 
>
>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] Changing link flags for one target

[Hendrik Sattler]

You could try a generator expression with a custom target property.

Am 4. Juli 2018 04:27:58 MESZ schrieb Andrew White :
>In my cross-compile environment for an embedded platform, I need to set
>the stack size for each executable.  The linker flag to set the stack
>size is (for example) "-Wl,-elf2flt='-s 2'".
>
>Is there an easy way to set this flag for every executable except one,
>for which I set "-Wl,-elf2flt='-s 4'"?  Obviously I can call
>   Set_target_properties( PROPERTIES LINK_FLAGS "-Wl,-elf2flt='-s
>2'")
>on each target, but is there a mechanism to make this the default and
>then set a different value on a single target?
>
>If necessary, I suspect "-Wl,-elf2flt='-s 2' -Wl,-elf2flt='-s
>4'" will produce the correct result.
>* can I avoid doing it like this?
>* how can I be sure that the more specific option will follow the
>general one?
>
>(Assume all the targets are added via add_subdirectory commands that
>are common across multiple platforms, and that I'm adding
>platform-specific build rules in the project CMakeLists.txt)
>
>Thanks
>
>--
>Andrew
-- 

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] Changes to cmake_minimum_required() for 3.12

[Hendrik Sattler]

Thanks for the link.
The backwards compatibility is something worth mentioning in the release notes, 
so that people can use it right away.


Am 1. Juli 2018 00:12:19 MESZ schrieb Craig Scott :
>(Subject changed to be specific to this discussion)
>
>On Sat, Jun 30, 2018 at 3:13 PM, Hendrik Sattler
>
>wrote:
>
>> It would actually make even more sense to rename
>cmake_minimum_required()
>> to cmake_version_required() with the new syntax or something similar.
>Users
>> of the old function cannot use the new syntax in older cmake versions
>and
>> the old name does not actually fit the new functionality.
>>
>
>Actually older versions can use the new syntax and this is indeed the
>specific reason why the new syntax is the way it is. Older CMake
>versions
>will see the extra dots as being version component separators and will
>end
>up effectively ignoring the max part. The nett result is that older
>versions will continue to treat the min version as the policy setting
>just
>like they have been to date. Newer versions of CMake will be able to
>take
>advantage of the extra information provided by the max part to allow
>newer
>policies to be enforced.
>
>Regarding the renaming, a very similar discussion took place in the
>merge
>request itself, so I'll refer you to there for details:
>
>https://gitlab.kitware.com/cmake/cmake/merge_requests/1864#note_389157
>
>
>
>
>>
>> Am 30. Juni 2018 00:05:25 MESZ schrieb "Alan W. Irwin" <
>> ir...@beluga.phys.uvic.ca>:
>> >On 2018-06-29 14:46-0400 Robert Maynard wrote:
>> >[...]
>> >> * The "cmake_minimum_required()" and "cmake_policy(VERSION)"
>> >>  commands now accept a version range using the form
>> >>  "[...]". The "" version is required but policies
>are
>> >>  set based on the "" version.  This allows projects to
>specify a
>> >>  range of versions for which they have been updated and avoid
>> >>  explicit policy settings.
>> >[...]
>> >
>> >I suggest the following change to the above description:
>> >
>> >but policies are set based on the "" version.
>> >
>> >==>
>> >
>> >but policies are set based on the minimum of the running CMake and
>> >"" versions.
>> >
>> >I prefer the latter because it immediately answers the question
>implied
>> >by the former, i.e.,
>> >what happens if the running version is less than max?
>>
>
>Seems reasonable. I've created a MR with a slight tweak to your wording
>for
>this here <https://gitlab.kitware.com/cmake/cmake/merge_requests/2180>.
>
>-- 
>Craig Scott
>Melbourne, Australia
>https://crascit.com
-- 

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] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing

[Hendrik Sattler]

It would actually make even more sense to rename cmake_minimum_required() to 
cmake_version_required() with the new syntax or something similar. Users of the 
old function cannot use the new syntax in older cmake versions and the old name 
does not actually fit the new functionality.


Am 30. Juni 2018 00:05:25 MESZ schrieb "Alan W. Irwin" 
:
>On 2018-06-29 14:46-0400 Robert Maynard wrote:
>[...]
>> * The "cmake_minimum_required()" and "cmake_policy(VERSION)"
>>  commands now accept a version range using the form
>>  "[...]". The "" version is required but policies are
>>  set based on the "" version.  This allows projects to specify a
>>  range of versions for which they have been updated and avoid
>>  explicit policy settings.
>[...]
>
>I suggest the following change to the above description:
>
>but policies are set based on the "" version.
>
>==>
>
>but policies are set based on the minimum of the running CMake and
>"" versions.
>
>I prefer the latter because it immediately answers the question implied
>by the former, i.e.,
>what happens if the running version is less than max?
>
>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.sf.net); 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] Dependencies with static libraries

[Hendrik Sattler]

Are you sure you hit the right build menu item? Maybe you are just building the 
current target. At least that would explain it. In MSVC you must either build 
the solution or the ALL_BUILD target for this to work.


Am 28. Juni 2018 16:07:33 MESZ schrieb Stephan Menzel 
:
>Hello CMake community,
>
>I am observing a strange problem regarding dependencies to static libs
>in
>executables. I am not entirely sure but it seems this started since I
>upgraded to the 3.11 line. I am using Windows and MSVC14.
>
>Basically, my code base contains a number of static libraries that are
>linked together to a few executables. Very basic and down to earth.
>Like
>this:
>
>set(MY_SERVER_SRC
>ServerSource1.cpp
>ServerSource2.cpp
>)
>
>set(MY_SERVER_HDR
>ServerConfig.hpp
>Header1.hpp
>Header2.hpp
>)
>
>add_library(my_server STATIC ${MY_SERVER_SRC} ${MY_SERVER_HDR})
>target_link_libraries(my_server
>some_tools
>some_base
>${Boost_LIBRARIES}
>${OPENSSL_LIBRARIES}
>)
>add_executable(serverd main.cpp)
>target_link_libraries(serverd
>my_server
>some_tools
>some_base
>
>${Boost_LIBRARIES}
>${OPENSSL_LIBRARIES}
>)
>
>So a few big libs with the beef in them and then a small main.cpp
>containing executable. Nothing fancy.
>
>What gives me trouble now is that dependencies within that seem broken.
>In
>above example, when I edit ServerSource1.cpp and then hit "Build", I
>see
>ServerSource1.o being compiled and the library my_server being linked.
>Like
>expected. Problem is, serverd does not get linked. Or at least I see no
>hint of it being linked (In MSVC's output window).
>So, my question is: What could cause this? I there anything 3.11.x does
>differently which causes those dependecies to break? And how can I fix
>this?
>
>This is quickly turning into a major problem for us here as it means
>that
>we cannot reliably build anymore because whenever we change something
>and
>hit build we can't be sure we get a linked executable anymore unless we
>do
>a complete rebuild, which takes a long time (In fact, I wrote this
>message
>waiting for one).
>
>Thanks for any hint!
>
>Stephan
-- 

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] Reason for deprecation of GenerateExportHeader ?

[Hendrik Sattler]

Am 8. Juni 2018 22:38:06 MESZ schrieb "Jean-Michaël Celerier" 
:
>Hello,
>
>the documentation page
>https://cmake.org/cmake/help/v3.11/module/GenerateExportHeader.html has
>the
>mention :
>
>> This function is deprecated. Set the target properties
>CXX_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN instead.
>
>Why is that so ? I don't know any library that would export either all
>or
>none of its symbols ; functions & types of the public API must always
>be
>chosen manually by the author of the library anyways. The only use of
>CXX_VISIBILITY_PRESET is to set the visibility to hidden by default, so
>that code can then use the export macros defined by the generate_export
>_
>header code to make specific symbols visible.

The deprecation only refers to the ADD_COMPILER_EXPORT_FLAGS, not the whole 
module.


>Best,
>Jean-Michaël
>
>---
>Jean-Michaël Celerier
>http://www.jcelerier.name
-- 

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] Spaces in conditional output of generator expressions

[Hendrik Sattler]

Am 3. Juni 2018 16:33:12 MESZ schrieb Marc CHEVRIER :
>In fact, the right way to manage « composite » options is to use «
>SHELL: »
>prefix (introduced in up-coming version 3.12).

Can you modify the example to show its use?
Why is it called shell? IMHO a build to its not required to use any kind of 
shell.

>Le dim. 3 juin 2018 à 16:11, Neil Carlson  a
>écrit :
>
>> Something not immediately obvious to me, and perhaps not to others
>that
>> might come across this thread, is that all spaces in the option
>string need
>> to be replaced with a semicolon, and not just those that separate
>options
>> (with Linux/make at least). For example  an option that takes an
>argument
>> '-assume realloc_lhs'. If you do this:
>>
>> BAD: add_compile_options("$<$:-assume
>> realloc_lhs>")
>>
>> you get a single quoted token "-assume realloc_lhs" on the compile
>line
>> which the compiler doesn't understand. The correct thing is
>>
>>
>> GOOD:
>add_compile_options("$<$:-assume;realloc_lhs>")
>>
>>
>> On Sun, Jun 3, 2018 at 7:33 AM Neil Carlson
>
>> wrote:
>>
>>>
>>> On Sun, Jun 3, 2018 at 7:08 AM Marc CHEVRIER
>
>>> wrote:
>>>
 [...]
 GOOD: target_compile_options(someTarget PRIVATE
  "$<$:-Wall;-Wextra>")

>>>
>>> Ah, that's it. Never occurred to me to quote the whole thing,
>thinking
>>> that would turn the generator expression into a literal string and
>not be
>>> interpreted.  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
>>
-- 

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] losing CMakeCache.txt after changing the compiler...

[Hendrik Sattler]

Hi,

I also found that e.g. Qt Creator throws away the cache too eagerly, e.g. when  
changing the deployment target IP address on the kit.

This led me to finding a solution for keeping command line definitions 
elsewhere because relying on the cache will hurt you bad sometimes.

Maybe more project-foreign people need to test cmake-enabled IDEs and ask for 
better behavior.

Otoh, cmake also should not rely that hard on its cache. When I upgrade the Qt 
installation and delete the old one, cmake fails hard where only a cmake expert 
can recover easily from. Why can't it check that cache file locations still 
exist when it runs? 

When I upgrade gcc on linux, cmake doesn't notice at all, although almost all 
derived values are wrong at that point.

HS


Am 2. Juni 2018 11:43:02 MESZ schrieb "René J.V. Bertin" :
>Hi,
>
>This happened once too often for me: I apply successive tweaks to a
>CMakeCache file, reinvoke make (or ninja) and then at some point lose
>everything because I forgot that changing the compiler is a "lethal"
>operation.
>
>Why does cmake have to throw away the entire cache file when something
>changes in the compiler path? That seems like a cheap way to implement
>a "let's keep track of which cached settings depend on the choice of
>compiler". At the least it wouldn't be much less cheap to rename
>CMakeCache.txt to CMakeCache.bak instead of deleting it.
>
>And FWIW, this is also a situation in which storing the exact CMake
>invocation in a comment at the top of the cache file could be useful...
>
>R.
-- 

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] pkg-config file format versus CMake packages

[Hendrik Sattler]

Hi,

I often found pkg-config files to be even wrong. Many library authors do not 
seem to know the rules for transitive linking. Often, the differences between 
static and dynamic linking is not or wrongly expressed in .pc files. Cross 
compiling with pkg-config is also not being the most fun unless the library 
author thought about it or you fix the files yourself.

You don't have to care so much about ABI, different compilers and such. On most 
systems, these need different directories and thus separate .pc files.

CMake also fails late at linking even pointing it to Qt 64bit libraries for a 
32bit compiler even though they use config modules! At some point, it's the 
responsibility of the developer to organize his environment correctly.

Regards,

HS



Am 26. Mai 2018 12:08:01 MESZ schrieb Lectem :
>
>Hi,
>I’ll start by saying that I love the fact we’re now talking about a
>common representation of packages !
>
>➢ The reason I say this is that extending pkg-config seems like it
>would help adoption rather then creating a completely new format. There
>is already a good portion of open source projects that already support
>pkg-config, so tweaking them to support more complicated scenarios
>seems easier than converting everything to a new format.
>
>I’m not very familiar with pkg-config (working more in the Windows
>world) so excuse me if I’m wrong.
>
>From what I remember it is very basic and relies on compiler flags
>being the same everywhere (ie gcc-like flags), and does not provide any
>information about things such as ABI, C-runtime Library used (arguably
>could be represented as a package ?). As far as I know, it assumes that
>the libraries are always compiled with the same compiler on the same
>system, hence has no knowledge of compatibility between compiler
>versions. 
>As you mentionned, it currently relies on -l for both libraries and
>linker flags, which would need to be changed.
>
>➢ so tweaking them to support more complicated scenarios seems easier
>than converting everything to a new format.
>
>Wouldn’t that create more confusion ? I fear it’d end up as a python2
>python3 issue, where both versions look alike but are incompatible.
>
>
>Have a nice Week-end,
>Lectem
-- 

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] Copying Shared Libraries (DLLs) Next to the Executable

[Hendrik Sattler]

Am 22. Februar 2018 04:20:40 MEZ schrieb "Marek Vojtko (Firaxis)" 
:
>I was looking into GetPrerequisites and FixupBundle, but both of those
>operate on an already existing executable and try to guess what shared
>libraries (DLLs) it might need. It feels silly to guess at something
>that CMake already knows (as the IMPORTED target sets the
>IMPORTED_IMPLIB and IMPORTED_LOCATION properties).

Actually at the point of installation this is the best approach especially for 
multi-config generators like e.g. Visual Studio. Else you'd have to know if a 
found .lib file is a shared or a static library (how?) and what DLL file it 
references. That's actually much more work than just looking at the actually 
dependencies of the binaries. Additionally if you don't exactly know for 3rd 
party binaries or plugins.

Catching all directories to find the dll files is also not simple but easier.

HS

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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] Config.cmake.in: Conditionally serve static or shared library

[Hendrik Sattler]

Am 14. Februar 2018 21:47:24 MEZ schrieb Kim Walisch :
>Thanks, I got it working!
>
>Unfortunately I could not make the generator expression work inside
>PrimesieveConfig.cmake.in, here is the error message:
>
>CMake Error:
>  Error evaluating generator expression:
>$
>  Expression did not evaluate to a known generator expression
>
>Note that in my main CMakeLists.txt the generator expression worked
>fine. But I figured out I don't actually need the generator expression,
>the following code inside my PrimesieveConfig.cmake.in does the trick:
>
>if(BUILD_SHARED_LIBS)

This is IMHO using the wrong variable! This variable tells that I want to build 
MY libs as static, not that I want to link 3rdParty libs statically!
At least this is surprising behavior.

OTOH and luckily, there are still the real targets to choose from.

>This trick is also used by the c-ares library:

Others also doing this wrong does not make it any better.

HS

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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] Dual use for single source file

[Hendrik Sattler]

Hi,

I also fell into this trap before:
Don't use MAIN_DEPENDENCY but DEPENDS.

HS


Am 15. Januar 2018 12:19:37 MEZ schrieb "christoph@ruediger.engineering" 
:
>Hi folks,
>
>we’re using a clang-based tool for co-processing a bunch of our source
>files. The benefit is, that it understands the compile_commands.json
>database and hence we do not need to pull out the include paths and the
>compile definitions by hand. However, CMake does not compile the source
>file any longer when used as input to a custom command.
>
>Here is the simplest project I could come up with to demonstrate the
>behavior:
>
>--- snip ---
># CMakeLists.txt
>cmake_minimum_required(VERSION 3.1)
>project(hello-world)
>
>add_executable(hello main.cxx hello.cxx)
>
>add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/reflections.h
>COMMAND echo "// This is a tool which creates type reflections"
>>reflections.h
>  MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/hello.cxx
>  COMMENT "Generating reflections"
>)
>--- snip ---
>
>--- snip ---
>// main.cxx
>void print_hello();
>
>int main() {
>  print_hello();
>  return 0;
>}
>--- snip ---
>
>--- snip ---
>// hello.cxx
>#include 
>
>void print_hello() {
>  std::cout << "Hello world!\n";
>}
>--- snip ---
>
>What happens is, that CMake does not compile hello.cxx any longer. It
>only executes the custom command. Consequently, the
>compile_commands.json database does not contain any information about
>hello.cxx. Tested on cmake 3.9.1 and 3.10.1.
>
>The reason for this behavior seems to be, that there can be only one
>kind for each given source file. In
>cmGeneratorTarget::ComputeKindedSources, there is an explicit check for
>not adding a source file multiple times to the KindedSources vector.
>And when checking which kind a source file is of, the first check is
>for custom commands. CMake says “Bingo, this is a custom command” and
>does not check whether it can be of any other kind as well.
>
>Is this a keep-it-simple implementation or is there any deeper
>knowledge behind this behavior?
>
>And more important: how can I force CMake to compile a source file and
>process it by a custom command?
>
>Thanks for your help,
>Christoph
>
>--
>rüdiger.engineering
>Christoph Rüdiger
>Düsseldorfer Str. 12
>45145 Essen
>Germany
>
>phone: +49 201 458 478 58

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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] How to find dll's on Cygwin? (fwd)

[Hendrik Sattler]

Hi,

looking at the location of the gnat static library, it seems to be a compiler 
library like libm. You usually do not use find_package on those but directly 
use -lgnat and the compiler knows how to find it. Requesting static linking 
will also work then.

HS


Am 28. Oktober 2017 05:38:19 MESZ schrieb "Alan W. Irwin" 
:
>On 2017-10-27 22:31+0200 Marco Atzeri wrote:
>
>> On 27/10/2017 09:32, Alan W. Irwin wrote:
>>> I am pretty sure there are a non-zero number of CMake users here who
>>> have had CMake experience finding dll's on Cygwin (since it appears
>>> from the quote below that import libraries can be replaced by dll's
>>> for the purposes of linking on that platform).  So if you are one
>with
>>> such experience, I would really appreciate an answer to (or commment
>>> on) the specific question below concerning finding cyggnat-6.dll on
>>> Cygwin or if you prefer to frame your response to the more general
>>> question of finding dll's on that platform, that would be great as
>>> well.
>>> 
>>> Alan
>>
>> using the import library is the standard way for linking,
>> looking for the shared library is surely unusual.
>>
>> I am not a user of ADA, but the import libraries seems
>> the one on /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/
>
>Hi Marco:
>
>Thanks for your input to the discussion.
>
>I believe you are referring to
>/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/libgnat.a
>
>(at least that appears to be the only library candidate I can come up
>with
>by searching for the RE
>
>"usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/.*gnat"
>
>using the  package search
>engine.)
>
>Our understanding is the Cygwin naming convention for the various
>kinds of libraries would be (in the gnat library case)
>
>dll   cyggnat-6.dll
>import librarylibgnat-6.dll.a
>static librarylibgnat.a
>
>If you use the above search engine to search for the RE "gnat.*dll" it
>only finds the above dll and no corresponding import library.
>
>We are pretty sure from its name that libgnat.a is just a static
>library. Anyhow, when we link our test_ada library against libgnat.a
>that link does appear to work, but afterward when linking Ada
>executables against our Ada library (which involves a gnatlink step
>with hidden link to one form of the gnat library but likely also
>cyggnat-6.dll) we get multiple symbol definition errors. That linking
>inconsistency does not happen if we link our Ada library against
>cyggnat-6.dll so it appears that is the library CMake needs to find in
>this case.
>
>Which neatly ( :-) ) leads back to my original question which is what
>is the
>best CMake logic to find that dll?
>
>Alan
>
>__
>Alan W. Irwin
>
>Astronomical research affiliation with Department of Physics and
>Astronomy,
>University of Victoria (astrowww.phys.uvic.ca).
>
>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.sf.net); 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:
>http://public.kitware.com/mailman/listinfo/cmake

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] SWIG CMAKE project not linked correctly

[Hendrik Sattler]

Am 15. September 2017 15:23:42 MESZ schrieb Bruce Jones 
:
>Hi,
>
>I have a relatively simple SWIG - CMAKE project that is not linked
>correctly, source files can be downloaded here:
>https://drive.google.com/open?id=0B4Y0idbHnikgTUlocmQtNDY2czQ
>
>The problem I have is if the template function Foo is implemented in
>the
>header file, the project compiles and works successfully. If Foo is
>instead
>implemented in the cpp file, the project compiles but fails either when
>linking on at runtime on Windows and Linux respectively.

Templated member functions must be defined in the header. Exceptions are 
explicitly instantiated ones for certain template parameter values.

>On windows the build will fail at linking with "unresolved external
>symbols", as though the template function is not instantiated.
>
>On Linux python fails to import the module with "undefined symbol".
>
>If I build the projects by hand (not with CMake) they compile and link
>successfully, and run successfully.

Strange. it should not work because the method definition in the cpp file will 
not result in any symbol due to unknown type T. So what are you doing 
differently? Some commands must differ.

HS

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] INTERPROCEDURAL_OPTIMIZATION still not using CMAKE__COMPILER_AR

[Hendrik Sattler]

Am 1. August 2017 22:52:09 MESZ schrieb Brad King :
>On 07/22/2017 07:33 AM, lec...@gmail.com wrote:
>> So I downloaded the 3.9 release and thought my LTO nightmares we over
>but
>> cmake still isn't using CMAKE__COMPILER_AR when linking on
>MSYS.
>
>The problem is that this code:
>
>https://gitlab.kitware.com/cmake/cmake/blob/v3.9.0/Modules/Platform/Windows-GNU.cmake#L117-127
>
>inserts use of the archiver into the main linking process as a way
>to work around Windows command-line length limits.  Since it is
>using the archiver as part of linking instead of just for creating
>a static library, our logic to switch to CMAKE__COMPILER_AR
>for LTO is not triggering.

And the code to detect that gcc uses GNU ld is broken as it does not check if 
gcc was actually built using the right configure flags!
If it isn't configured for GNU ld, it does not forward the response file to the 
collect2 command and the command line length thing breaks it. This is 
independent of the actual ld binary.

HS


-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Transitive behavior of target_link_libraries between shared/static

[Hendrik Sattler]

Am 18. Juli 2017 18:02:40 MESZ schrieb Eric Noulard :
>2017-07-17 17:31 GMT+02:00 Robert Dailey :
>
>> Suppose I have the following:
>>
>> ```
>> add_library( A STATIC ${files} )
>>
>> add_library( B SHARED ${more_files} )
>> target_link_libraries( B PUBLIC A )
>>
>> add_library( C STATIC ${even_more_files} )
>> target_link_libraries( C PUBLIC B )
>>
>>
>> add_executable( D ${exe_files} )
>> target_link_libraries( D PRIVATE C )
>> ```
>>
>> Does the linker command for target `D` ever see target A's static
>link
>> library? I'm hoping the only thing the linker gets is `libB.so` and
>> `libC.a`, without `libA.a`.
>>
>
>I guess it does otherwise you may be missing symbols.
>As explain by Peter some time ago:
>  https://cmake.org/pipermail/cmake/2017-April/065347.html
>when you
>target_link_libraries( B PUBLIC A )
>
>with A being STATIC you do not really link A into B (which is shared in
>your example)

You confused PUBLIC and INTERFACE in your response.
target_link_libraries( B PUBLIC A ) DOES link A into B but only the symbols 
needed by B.

The link to the old post has it all right.

HS


-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Generating include files

[Hendrik Sattler]

Am 20. Mai 2017 11:16:54 MESZ schrieb Urs Thuermann :
>Craig Scott  writes:
>> add_executable(foo foo.c)
>> set_source_files_properties(foo.c PROPERTIES OBJECT_DEPENDS
>> ${CMAKE_BINARY_DIR}/tab.h)
>
>IMO that feels just wrong.  foo.c does NOT depend on tab.h, foo.c does
>not depend on anything, it's not even generated by the build system.
>*I* edit it.  Instead, it is the object file foo.o that depends on
>tab.h.  But it seems that cmake doesn't want the developer to see or
>talk about object files.  It hides them somewhere in subdirs (with
>unpredictable names (sometimes foo.o, sometimes a silly name like
>foo.c.o, sometimes both), so after make foo.o I don't know which one
>is current), gives error messages if I use them in CMakeLists.txt...

This is not quite correct.
Either your code generates a header file to be included by foo.c, then foo.c 
depends on it. Or it creates data and methods that need to be linked, then the 
executable depends on it.

An object file only makes the executable need unresolved symbols but that is 
not a dependency of the object file.

Or you simply failed to explain how parts relate to each other and the 
dependency between the parts is totally different.

OTOH, table-driven CRC is usually not that complicates to integrate.

CMake handles lots of compilers that REQUIRE other object file extensions than 
.o. It also generates for more that only make, allowing better working with 
IDEs. These bring their own strange rules that you cannot match to any make 
logic.

HS

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] DLL handling under CMake

[Hendrik Sattler]

Hi,

sorry for the delay. I see you already found a solution yourself.
Still, I want to share mine:
-CopyPrerequisites.cmake
include ( GetPrerequisites )

if ( NOT DEFINED PREREQ_FILE )
  message ( FATAL_ERROR "PREREQ_FILE must be defined(${PREREQ_FILE})" )
endif ()

#
# Satisfy the find_file() search by common subdirs where .dll file can  
be found

#
foreach ( dir ${CMAKE_PREFIX_PATH} )
  list ( APPEND dirs ${dir}/bin )
endforeach ( dir )

get_filename_component ( COPY_DESTINATION "${PREREQ_FILE}" PATH )
get_prerequisites ( "${PREREQ_FILE}" COPY_FILES 1 1 "${dirs}"  
"${COPY_DESTINATION}" )


foreach ( COPY_FILE ${COPY_FILES} )
  if ( NOT IS_ABSOLUTE ${COPY_FILE} )
set ( COPY_FILE_FULL )
gp_resolve_item ( "${PREREQ_FILE}" "${COPY_FILE}" "${dirs}"  
"${COPY_DESTINATION}" COPY_FILE_FULL )

  else ()
set ( COPY_FILE_FULL ${COPY_FILE} )
  endif ()
  if ( COPY_FILE_FULL )
get_filename_component ( COPY_SOURCE_DIR "${COPY_FILE_FULL}" PATH )
if ( NOT COPY_SOURCE_DIR MATCHES "^${COPY_DESTINATION}$" )
  message ( "Copying ${COPY_FILE_FULL} to output directory" )
  execute_process ( COMMAND "${CMAKE_COMMAND}" -E  
copy_if_different "${COPY_FILE_FULL}" "${COPY_DESTINATION}" )

endif ()
  else ()
message ( "Failed to find  ${COPY_FILE}" )
  endif ()
endforeach ( COPY_FILE )
--

This can now be called from CMakeLists.txt:
if ( CMAKE_RUNTIME_OUTPUT_DIRECTORY )
  add_custom_command ( TARGET Gui POST_BUILD
COMMAND ${CMAKE_COMMAND}
"-DCMAKE_PREFIX_PATH:PATH=${SOME_SEARCH_DIRS}"
"-DPREREQ_FILE=$"
-P ${CMAKE_SOURCE_DIR}/CMakeModules/CopyPrerequisites.cmake
VERBATIM
  )
endif ()

The variable SOME_SERACH_DIRS is filled with e.g. IMPORTED_LOCATION  
property values.
The same variable is used when calling INSTALL(CODE ".   
fixup_bundle(...)" )


Regards,

HS

Zitat von lec...@gmail.com:


I managed to get it working by using an intermediate script.
One might want to generate the script instead of using the  
« RUN_IT » variable trick.

This was only tested on Windows, but seems to work fine.
Put the following code in a xx.cmake file, include it from your  
CMakeLists.txt and enjoy.



# This is a helper script to run BundleUtilities fixup_bundle as postbuild
# for a target. The primary use case is to copy .DLLs to the build  
directory for
# the Windows platform. It allows generator expressions to be used  
to determine

# the binary location
#
# Usage : run_fixup(TARGET LIBS DIRS)
# - TARGET : A cmake target
# - See fixup_bundle for LIBS and DIRS arguments

if(RUN_IT)
# Script ran by the add_custom_command
include(BundleUtilities)
fixup_bundle("${TO_FIXUP_FILE}" "${TO_FIXUP_LIBS}" "${TO_FIXUP_DIRS}")
# End of script ran by the add_custom_command
else()

set(THIS_FILE ${CMAKE_CURRENT_LIST_FILE})
message(${THIS_FILE})
function(run_fixup _target _libs _dirs)
message(${THIS_FILE})
add_custom_command(
TARGET ${_target} POST_BUILD
		COMMAND ${CMAKE_COMMAND} -DRUN_IT:BOOL=ON  
-DTO_FIXUP_FILE=$<TARGET_FILE:${_target}> -DTO_FIXUP_LIBS=${_libs}  
-DTO_FIXUP_DIRS=${_dirs}  -P ${THIS_FILE}

COMMENT "Fixing up dependencies for ${_target}"
VERBATIM
)

endfunction()

endif()


De : Clément Gregoire
Envoyé le :jeudi 4 mai 2017 08:37
À : Hendrik Sattler; Louis-Paul CORDIER; Cmake Mailing List
Objet :Re: [CMake] DLL handling under CMake

I'd also be interested in this. I saw an old mail in the ML about  
this, but it seems fixup_bundle is old and cant use generator  
expressions, making it hard to use (I don't want to hardcode the  
executable path).


Do you have a sample for this ?
CMake would really benefit from having those features made more  
accessible instead of everyone having to write its own script 
Le sam. 29 avr. 2017 22:10, Hendrik Sattler  
<p...@hendrik-sattler.de> a écrit :



Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER  
<lp.cord...@dynamixyz.com>:

This steps are tedious and I'm wondering if there is a mechanism that
exists or that have to be imagined to make the DLL nightmare end.


I use BundleUtilities to achieve the copying of DLL files to the  
installation directory. The main problem for this is to enumerate  
the needed directories.


I use the same for copying DLL files to the output directory to ease  
debugging.


The advantage is the inspection of the exe for really needed DLL  
files. This AUTOMATICALLY handles the case debug vs. release.


HS

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
--

Powered by www.kitware.com

Please keep messages on-to

Re: [CMake] DLL handling under CMake

[Hendrik Sattler]

Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER 
:
>This steps are tedious and I'm wondering if there is a mechanism that 
>exists or that have to be imagined to make the DLL nightmare end.

I use BundleUtilities to achieve the copying of DLL files to the installation 
directory. The main problem for this is to enumerate the needed directories.

I use the same for copying DLL files to the output directory to ease debugging.

The advantage is the inspection of the exe for really needed DLL files. This 
AUTOMATICALLY handles the case debug vs. release.

HS

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] check_c_source_compiles caching pitfalls

[Hendrik Sattler]

Am 23. April 2017 03:16:41 MESZ schrieb Tyson Nottingham 
:
>The result of check_c_source_compiles and similar commands
>(check_c_source_runs, check_cxx_source_compiles, etc.) is cached by the
>variable name passed in. This caching makes those commands and ones
>that
>depend on them easy to misuse.
>
>For example,
>
>set(potential_flags -Wall -badflag)
>
>foreach(flag ${potential_flags})
>check_cxx_compiler_flag(${flag} has_flag)
>if(has_flag)
>set(flags "${flags} ${flag}")
>endif(has_flag)
>endforeach(flag)

Try to use variables with a better naming.  This will also solve your problem:
has_flag_${flag}

>Since the variable name "has_flag" is used on every loop iteration, the
>result of check_cxx_compiler_flag is the same on every iteration
>(because
>it uses check_cxx_source_compiles internally, which caches by variable
>name). Supposing -Wall is a valid flag, flags will be "-Wall -badflag",
>even if -badflag isn't valid.

Ask yourself WHY this is done! Rerunning cmake in a build tree should not 
repeat all those expensive tests. 

>The obvious workaround is to use different variable names for each
>check.
>For example:
>
>set(potential_flags -Wall -badflag)
>set(flag_test_counter 0)
>
>foreach(flag ${potential_flags})
>math(EXPR flag_test_counter "${flag_test_counter} + 1")
>set(flag_test "flag_test_${flag_test_counter}")
>check_cxx_compiler_flag(${flag} ${flag_test})
>if(${flag_test})
>set(flags "${flags} ${flag}")
>endif(${flag_test})
>endforeach(flag)
>
>But there is still a problem with this. If I run this once, flags will
>be
>"-Wall". If I change potential_flags to "-Wall -Werror" (supposing
>-Werror
>is valid) and run it again, flags will still be "-Wall" because of the
>caching. The test on -Werror will use the results for the test on
>-badflag.
>
>This problem can just as easily occur in simpler situations.
>
>check_cxx_compiler_flag(-Wall has_flag)
>
>if(has_flag)
>message("yep")
>endif(has_flag)
>
>If I run this once, change -Wall to -badflag, and run it again, I'll
>still
>enter the if block.
>
>The obvious workaround is to delete the build files after changing
>potential_flags.
>
>However, all of this seems pretty error prone. I'm new to CMake, so I
>may
>be missing something obvious. Is there an obvious non-error-prone
>solution
>to this? In future versions, can these commands take arguments that say
>not
>to use the cached result (or something along those lines)? At the very
>least, the documentation for the commands and those that depend on them
>could mention these pitfalls.

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] New Visual Studio project types

[Hendrik Sattler]

This is not cross-platform:
"Today Visual Studio only supports building remotely on the Linux target 
machine."


Am 16. April 2017 08:19:49 MESZ schrieb Robert Bielik :
>Hi all,
>
>With the "new" Cross-platform project types in VS2015+
>(https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/),
>it's almost ridiculously easy and fun to develop X-platform on f.i. the
>raspberry pi.
>
>I have a CMake based console app which I'd like to use with the
>X-platform tools above, is this in the works for the CMake VS generator
>? Any other ideas on how to cram in an existing CMake project with the
>VC linux dev stuff ?
>
>Regards
>/Robert

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to properly handle build version number in CMake script for project

[Hendrik Sattler]

Hi,

You could make it a non-cache variable and manage the caching yourself. The 
cache is your version.cmake. Before including it, check if the variable is set 
and update your version cmake file, possibly with configure_file().  After 
that, unset() the cache variable and include your cmake file, this having a 
non-cache variable. Add the cmake file to the list of dependent files to let 
cmake run when that file changes.

Regards

HS


Am 10. April 2017 15:29:20 MESZ schrieb Robert Dailey 
:
>I have a file called version.cmake that my root CMakeLists.txt
>includes. There is only a single line in this file:
>
>set( BUILD_VERSION 1.2.3.4 CACHE STRING "Version of the product" )
>
>I have two scenarios where this version number setting needs to work
>slightly differently from a CMake perspective:
>
>1. Our CI build server does a fresh clone of our repo, and generates
>from scratch. It sometimes needs to override the version number from
>the command line via arguments. So it will do:
>
>-D BUILD_VERSION=99.99.1.2
>
>This works since it's a cache variable. In fact, the current solution
>ONLY works well for this scenario (since it will allow overriding from
>command line, but also allow the file to set the value if it is not
>specified as a -D argument).
>
>2. Local work machine builds. Local builds never override using -D,
>they always use what is in the version.cmake file. However, because
>it's a cache variable and I'm not using FORCE with set(), it never
>updates if I change the version and push it to origin. This is the
>missing requirement: it needs to update when the number (value)
>changes in version control
>
>I thought of making a BUILD_VERSION_OVERRIDE that is only accepted on
>the command line, and if specified, it will set the BUILD_VERSION
>value to the overridden value. However, I don't like the idea of 2
>separate variables to manage this. Using a non-cache variable doesn't
>allow overriding with the same variable value on the command line
>either.
>
>What's the best solution here for my situation?

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] custom command comments not showing up

[Hendrik Sattler]

However, this messes up parallel make progress output.

Am 7. April 2017 22:22:08 MESZ schrieb Craig Scott :
>Unfortunately, COMMENT is unreliable. Some generators will honour it,
>others won't. A more robust alternative is to use CMake's command mode
>to
>echo the comment instead. Eg:
>
>add_custom_command( TARGET zApp_zip POST_BUILD
>COMMAND ${CMAKE_COMMAND} -E echo "test2"
>COMMAND ${CMAKE_COMMAND} ARGS ...snip...
>)
>
>
>
>On Fri, Apr 7, 2017 at 11:40 PM, Robert Dailey
>
>wrote:
>
>> So I probably am not understanding how this works.
>>
>> I have a custom target, that I later add multiple custom commands to.
>> Each custom command has a COMMENT set, but the target itself does
>too:
>>
>> add_custom_target(zApp_zip COMMENT "test1")
>>
>> add_custom_command( TARGET zApp_zip POST_BUILD
>> COMMAND ${CMAKE_COMMAND} ARGS ...snip...
>> COMMENT "test2"
>> )
>>
>> Instead of seeing "test1" or "test2" when running, I get:
>>
>> $ ninja zApp_zip
>> [1/1] Running utility command for zApp_zip
>>
>> Why does it say "Running utility command"? What is the behavior of
>all
>> the comments supposed to be? Is this a ninja-specific issue or
>> behavior?
>> --
>>
>> 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:
>> http://public.kitware.com/mailman/listinfo/cmake
>>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Desktop icon not safe (missing +x ) on cmake deb file

[Hendrik Sattler]

Hi,

Desktop files and icons do not need any execute permissions. They are only data 
files. The executable that the desktop file points to must be executable, 
though. To mount the NTFS partition as a user, use either pmount or your 
desktop mount utility.

OTOH, you make your life unusual hard by using NTFS on Linux for more than pure 
data storage.

HS


Am 19. März 2017 20:41:30 MEZ schrieb "Gonzalo Garramuño" :
>
>
>El 19/03/2017 a las 15:13, Gonzalo Garramuño escribió:
>> Hi,
>>
>> I had a program which I compile with cmake.  This program was on an 
>> NTFS partition with permissions: defaults.  This meant all files were
>
>> owned by root with 777 permissions.   This worked fine but it was not
>
>> secure and created problems with the postrm/posinst scripts.
>>
>> Recently I tried changing my fstab to mount the partition with user 
>> and permissions,like:
>>
>> UUID=98222A3D222A20AC  /media/gga/Datos ntfs-3g 
>> auto,users,permissions,exec 0 0
>>
>> Now, when I package my application into a deb file, it works.  I get:
>>
>> -rw-r--r-- 1 gga gga 24M mar 19 14:55 mrViewer-v3.5.4-Linux-64.deb
>>
>I figured it out.  For reference, I had to change the fstab file to:
>
>UUID=98222A3D222A20AC  /media/gga/Datos ntfs-3g 
>auto,users,permissions,exec,uid=1000,gid=1000,umask=022 0 0

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Comaptibility with older gcc

[Hendrik Sattler]

If the target platform has an adapted gcc  that does not match upstream gcc, or 
may not be possible to just compile a newer version. Or it is a discontinued 
arch.


Am 27. Januar 2017 19:05:09 MEZ schrieb "Elizabeth A. Fischer" 
<elizabeth.fisc...@columbia.edu>:
>C++ code is not compatible between different compilers.  You cannot
>link
>C++ code built with GCC 4.9.3 with GCC 4.2.1.  Maybe if you hack around
>and
>find the GNU C++ libraries from your GCC 4.9.3 installation... just
>maybe,
>with enough hacking, it will work.  But in general, this is a rabbit
>hole
>that will offer you very little in the end.
>
>The standard way to build on systems that don't have the compilers you
>need
>is... to get the compilers you need.  My point was that getting these
>compilers is actually not very hard.  In the end, that will almost
>certainly be the easiest solution to your problem.
>
>
>On Fri, Jan 27, 2017 at 12:58 PM, Hendrik Sattler
><p...@hendrik-sattler.de>
>wrote:
>
>> Your answer is totally unrelated to the question.
>>
>> Am 27. Januar 2017 18:23:39 MEZ schrieb "Elizabeth A. Fischer" <
>> elizabeth.fisc...@columbia.edu>:
>> >Get spack, then use it to build GCC 4.9.3  takes a couple hours of
>wall
>> >time, five minutes of your time.
>> >
>> >Github.com/llnl/spack
>> >On Jan 27, 2017 12:04 PM, "Michele Portolan" <
>> >michele.porto...@grenoble-inp.fr> wrote:
>> >
>> >> I have a project that build correctly using gcc 4.9.3, generating
>a
>> >> dynamic library that I can later link to obtain my executables.
>So,
>> >nothing
>> >> special.
>> >>
>> >> My problem is that on one of my target systems, I only have a gcc
>> >4.1.2
>> >> and I am forced to use it for at least  linking the last
>executable.
>> >My
>> >> project uses extensively C++14,so I cannot build it with the older
>> >gcc.
>> >>
>> >> Is there a way to have Cmake generate a library that is compatible
>> >with
>> >> gcc 4.1.2?
>> >>
>> >> Regards,
>> >>
>> >>
>> >> Michele
>> >> --
>> >>
>> >> 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/opensou
>> >> rce/opensource.html
>> >>
>> >> Follow this link to subscribe/unsubscribe:
>> >> http://public.kitware.com/mailman/listinfo/cmake
>> >>
>>
>> --
>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>> gesendet.
>>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Comaptibility with older gcc

[Hendrik Sattler]

It depends very much on your target system. The C++-ABI between 4.9 and 4.1 may 
be compatible but that is not guaranteed. C++14 is also a bit unspecific:   
language features or library features? Does your library expose any C++11/14 
features in its interface?

It may just not be possible after all...

Am 27. Januar 2017 18:04:17 MEZ schrieb Michele Portolan 
:
>I have a project that build correctly using gcc 4.9.3, generating a 
>dynamic library that I can later link to obtain my executables. So, 
>nothing special.
>
>My problem is that on one of my target systems, I only have a gcc 4.1.2
>
>and I am forced to use it for at least  linking the last executable. My
>
>project uses extensively C++14,so I cannot build it with the older gcc.
>
>Is there a way to have Cmake generate a library that is compatible with
>
>gcc 4.1.2?
>
>Regards,
>
>
>Michele

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Comaptibility with older gcc

[Hendrik Sattler]

Your answer is totally unrelated to the question.

Am 27. Januar 2017 18:23:39 MEZ schrieb "Elizabeth A. Fischer" 
:
>Get spack, then use it to build GCC 4.9.3  takes a couple hours of wall
>time, five minutes of your time.
>
>Github.com/llnl/spack
>On Jan 27, 2017 12:04 PM, "Michele Portolan" <
>michele.porto...@grenoble-inp.fr> wrote:
>
>> I have a project that build correctly using gcc 4.9.3, generating a
>> dynamic library that I can later link to obtain my executables. So,
>nothing
>> special.
>>
>> My problem is that on one of my target systems, I only have a gcc
>4.1.2
>> and I am forced to use it for at least  linking the last executable.
>My
>> project uses extensively C++14,so I cannot build it with the older
>gcc.
>>
>> Is there a way to have Cmake generate a library that is compatible
>with
>> gcc 4.1.2?
>>
>> Regards,
>>
>>
>> Michele
>> --
>>
>> 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/opensou
>> rce/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] install() rename with version string

[Hendrik Sattler]

Am 20. Januar 2017 09:36:54 MEZ schrieb Wagner Martin 
:
> Thanks for your answers.
> 
> > >You will need to do the install as another target/command.  For
>> >example:
>> >
>> >add_custom_command( TARGET version
>> > POST_BUILD
>> > COMMAND ${CMAKE_COMMAND} -D
>> >VERSION=${version_string}
>> > -P install_commands.cmake
>> > USES_TERMINAL )
>> 
>> Or even simpler, do all of that in the install_commands.cmake by
>using
>> install(CODE) AND escaping the $.
>> Just looking at the generated install_commands.cmake will make this
>much
>> clearer.
>> 
>
>I think I don't properly understand what you mean. Can you please give
>me an example?
>
>I've tried
>
>install(CODE "
>  Include(version.cmake)
>install(FILES firmware.hex  RENAME  firmware_\${version_string}.hex
>DESTINATION firmware)
>")
>
>This is correctly expanded in generated "cmake_install.cmake" script,
>runs without errors, but does not install the file.

Well, the second install command has the wrong scope:
install(CODE "include(version.cmake)")
install(FILES firmware.hex 
RENAME  firmware_\${version_string}.hex
DESTINATION firmware)

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] install() rename with version string

[Hendrik Sattler]

Am 19. Januar 2017 15:26:47 MEZ schrieb "Gonzalo Garramuño" 
:
>
>
>El 19/01/17 a las 05:30, Wagner Martin escribió:
>>
>> However, CMake needs to include version.cmake at first CMake run
>time, 
>> which is not possible because it’s a generated file.
>>
>> Is there any other way to do the rename?
>>
>>
>You will need to do the install as another target/command.  For
>example:
>
>add_custom_command( TARGET version
> POST_BUILD
> COMMAND ${CMAKE_COMMAND} -D 
>VERSION=${version_string}
> -P install_commands.cmake
> USES_TERMINAL )

Or even simpler, do all of that in the install_commands.cmake by using 
install(CODE) AND escaping the $.
Just looking at the generated install_commands.cmake will make this much 
clearer.

HS

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] ExternalProject_Add

[Hendrik Sattler]

One possibility is the often mentioned superbuild, another is not using 
find_library() but setting the variables with the library file paths manually 
(that's static info anyway).


Am 8. Januar 2017 22:49:52 MEZ schrieb Saad Khattak :
>Hello,
>
>I have an external project glfw that I added to my project like this:
>
>==
>include(ExternalProject)
>ExternalProject_Add(glfw
>  GIT_REPOSITORY "https://github.com/glfw/glfw.git;
>  GIT_TAG "master"
>
>  SOURCE_DIR "${CMAKE_SOURCE_DIR}/dep/glfw"
>  CMAKE_ARGS -DGLFW_BUILD_DOCS=OFF -DGLFW_BUILD_TESTS=OFF
>-DGLFW_BUILD_EXAMPLES=OFF
>-DCMAKE_INSTALL_PREFIX=${CMAKE_SOURCE_DIR}/install/glfw/
>-DCMAKE_DEBUG_POSTFIX=_d
>
>  TEST_COMMAND ""
>  )
>set(GLFW_INCLUDE_DIR "${CMAKE_SOURCE_DIR}/install/glfw/include/")
>set(GLFW_LIBRARY_DIR "${CMAKE_SOURCE_DIR}/install/glfw/lib/")
>==
>
>Then I include it in my project like so:
>
>==
>find_library(GLFW_LIB_D  glfw3_d ${GLFW_LIBRARY_DIR})
>find_library(GLFW_LIBglfw3   ${GLFW_LIBRARY_DIR})
>
>include_directories(${GLFW_INCLUDE_DIR})
>
>add_executable(vk_test
>  src/vulkan_test.cpp
>  )
>target_link_libraries(vk_test debug ${GLFW_LIB_D} optimized
>${GLFW_LIB})
>add_dependencies(vk_test glfw)
>==
>
>As you can see, I depend on the libraries compiled by the external
>project
>glfw. Unfortunately, when I first configure the project, CMake
>complains
>that it cannot find the libraries specified by ${GLFW_LIB_D} and
>${GLFW_LIB} variables.
>
>Of course, this is because CMake did not begin cloning, configuring and
>building the glfw project. That only happens AFTER my project has been
>configured and starts building. This becomes a chicken and the egg
>problem.
>
>Currently, my solution is to add dummy .lib files so that I can at
>least
>configure and generate my project. My question is, am I approaching
>this
>problem in the wrong way? If yes, what is the correct way to add a
>dependency to an external project and have it clone/configure/build
>BEFORE
>the "find_library" call?

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMake 3.7.1 gui fails to launch

[Hendrik Sattler]

Am 6. Januar 2017 23:37:00 MEZ schrieb da...@daryllee.com:
>And the answer is...
>
>I recently installed an IDE from a not-to-be-named company that I do a 
>
>lot of business with.  The installation of that software places their  
>installation directory in LD_LIBRARY_PATH and guess what? their  
>installation contains a copy of libQtGui.so and libQtCore.so.  The  
>"ldd" tip led me to that discovery.  For now I have put  
>/usr/lib/x86_64-linux-gnu in front of their path in LD_LIBRARY_PATH  
>and cmake-gui V3.7.1 is working.  I may have to come up with a more  
>permanent fix, but for now their stuff seems to work and CMake seems  
>to work, so I'm claiming victory.

Maybe as a customer you should tell them about this bad experience. They should 
either set RPATH in their programs or should set LD_LIBRARY_PATH only in a 
start wrapper script.
In a program that lets the user start other programs, RPATH should be preferred 
or  LD_LIBRARY_PATH should be cleaned up for child processes.

HS

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Replacing Compile Options for a Target

[Hendrik Sattler]

Hi,

actually not all compilers do that. There are really strange ones out there.

HS


Am 7. Dezember 2016 06:31:02 MEZ, schrieb Dvir Yitzchaki 
:
>There's no problem as the compiler will just use the last flag value.
>See an example at http://coliru.stacked-crooked.com/a/738fff0fcc2eb3c4.
>
>Regards,
>
>Dvir Yitzchaki
>Debugger Software Engineer, SDT
>
>
>-Original Message-
>From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Jayesh
>Badwaik
>Sent: Wednesday, December 07, 2016 6:48 AM
>To: CMake 
>Subject: [CMake] Replacing Compile Options for a Target
>
>Hi,
>
>My global compile flags are specified with "std=c++14" in them.
>However, there is a third party header file which I want to compile in
>my code wherein I need to use a completely different set of compile
>flags starting with "-std=c++98". 
>
>I have seen target_compile_options() but that seems to just add options
>to the already available global options.  What command should I use to
>assign a completely new set of flags from the scratch. 
>
>--
>Cheers
>Jayesh Badwaik
>https://www.jayeshbadwaik.in

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] v3.7.0 - archive_cryptor_private.h - compile error

[Hendrik Sattler]

I assume that maybe he tries to build with openssl 1.1

Am 26. November 2016 09:29:14 MEZ, schrieb Gregor Jasny via CMake 
:
>Hello,
>
>On 25/11/2016 19:25, Nathan Sizemore wrote:
>> I receive the following when building:
>> 
>> [ 40%] Building C object
>>
>Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_cryptor.c.o
>> In file included from
>>
>/home/nathan/development/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor.c:32:0:
>>
>/home/nathan/development/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h:107:17:
>> error: field ‘ctx’ has incomplete type
>>   EVP_CIPHER_CTX ctx;
>
>You are using the embedded copy of libarchive. I would suggest you
>install the Debian CMake package build dependencies:
>
>  apt-get build-dep cmake
>
>so that you use the system libraries instead of the embedded ones.
>Hopefully this will resolve your issue.
>
>Thanks,
>Gregor
>-- 
>
>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:
>http://public.kitware.com/mailman/listinfo/cmake

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Proper way to support 64bit and 32bit builds

[Hendrik Sattler]

You need to set these compiler flags BEFORE the project() call to let CMake 
detect all stuff properly. There is a CMake  variable telling you the size of a 
void*.


Am 29. Oktober 2016 12:22:07 MESZ, schrieb cen :
>Hi
>
>Once I switch to 32bit builds, CMake fails to recognise that 
>glibc-devel.i686 is not installed resulting in an error when running
>make.
>In the same way, my own FindGMP fails to recognize that gmp-devel.i686 
>is not installed. I need CMake to fail if these things are missing.
>At least for the compiler part, I'm pretty sure I am missing some var
>or 
>flag to tell CMake I expect a 32 bit build.
>
>This is what I use to switch between builds in CMakeLists.txt (ARCH var
>
>is irrelevant here,  I use it later on for CPack):
>
>if (BUILD_32)
>set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS 
>"-m32" LINK_FLAGS "-m32")
> MESSAGE(STATUS "Excluding 64bit library paths from search.")
> set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS OFF)
> set(ARCH i686)
>elseif (BUILD_64)
>set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS 
>"-m64" LINK_FLAGS "-m64")
> set(ARCH amd64)
>else()
> set(ARCH amd64)
>endif()
>
>
>For the FindGMP module, I am not really sure what the best practice 
>is.Does the BUILD_32 and BUILD_64 flag propagate into the FindGMP? Do I
>
>explicitly specify paths for 32bit libs (eg: /usr/lib64) or can  cmake 
>be smarter than this?

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Prevent ExternalProject from updating git submodules

[Hendrik Sattler]

Hi,

you can tell git where your copy of tree remote url is. This is site-specific 
and does not change the repository:
git config remote."$origirl".url "$newurl"

HS


Am 25. Oktober 2016 03:52:12 MESZ, schrieb Tim Rae :
>Hi all,
>
>I'm using ExternalProject_Add to add the popular C++ library range-v3
>to 
>one of our projects. However, since the build server only has local 
>intranet access, and therefore can't access the main github repository,
>
>we have put a clone of that repo on our local gitlab:
>
>ExternalProject_Add(range-v3
> PREFIX ${PREFIX_DIR}
> GIT_REPOSITORY ${LOCAL_GITLAB_URI}
>)
>
>The problem is that range-v3 has a documentation submodule that points 
>to github, so `git clone ${LOCAL_GITLAB_URI} --recursive` would fail 
>when github is inaccessible, whereas git clone works fine without the 
>recursive flag.
>
>I found a previous message from Tim Gallagher on the mailing list 
>reporting the same problem, but it looks like the issue was never 
>addressed upstream.
>
>https://cmake.org/pipermail/cmake/2015-March/060100.html
>
>Unfortunately, specifying GIT_SUBMODULES "" will add all submodules, so
>
>it doesn't appear that variable will help to solve the issue. I would 
>suggest either having a special value like "__NONE__", or having a new 
>boolean variable like INIT_GIT_SUBMODULES; either of which can be used 
>to disable the automatic initialization of submodules entirely.
>
>You could also change the default to NOT pull in submodules. This would
>
>be much better IMHO, as the current behavior is unintuitive. Most 
>developers (e.g. myself until yesterday) don't even know what a 
>submodule is, and are only familiar with using git clone, as opposed to
>
>git clone --recursive. Obviously this would be a breaking change
>though, 
>so I understand that you probably don't want to go with this option.
>
>For now I have "solved" the problem by adding a new commit to our 
>range-v3 fork removing all git submodules, however this makes it more 
>difficult to get the upstream changes in, so I highly recommend adding 
>an option to disable the automatic initialization of git submodules.
>
>Best regards,
>Tim
>
>-- 
>*This correspondence (including any attachments) is for the intended 
>recipient(s) only. It may contain confidential or privileged
>information or 
>both. No confidentiality or privilege is waived or lost by any 
>mis-transmission. If you receive this correspondence by mistake, please
>
>contact the sender immediately, delete this correspondence (and all 
>attachments) and destroy any hard copies. You must not use, disclose,
>copy, 
>distribute or rely on any part of this correspondence (including any 
>attachments) if you are not the intended recipient(s). 本 
>メッセージに記載および添付されている情報 （以 下、総称して「本情報」といいます。）は、本来の受信者による使用のみを 意
>図しています。誤送信等により 
>本 情報を取得された場合でも、本情報に係る 秘 密、または法律上の秘匿特権が失われるものではありません。本電子メールを 受
>取られた方が、本来の受 
>信者ではない場合には、本情報及びそのコピー すべ てを削除・破棄し、本電子メールが誤って届い た旨を発信者宛てにご通知下さい ま
>すようお願いしま 
>す。本情報の閲覧、発信または本情報に基づく いかなる行 為も明確に禁止されていることをご了承くださ い。*
>-- 
>
>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:
>http://public.kitware.com/mailman/listinfo/cmake

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] cmake doesn't find QtCore

[Hendrik Sattler]

Hi,

what is your compiler?

HS


Am 18. Oktober 2016 02:07:35 MESZ, schrieb Spencer Parkin 
:
>Hi,
>
>I'm trying to install PySide.  With "pip install PySide", I get the
>warning...
>
>CMake Warning at c:/Program Files
>(x86)/Cmake/share/cmake-3.7/Modules/FindQt4.cmake:618 (message):
>C:/Qt/4.8.5/bin/qmake.exe reported QT_INSTALL_LIBS as "C:/Qt/4.8.5/lib"
>but
>QtCore could not be found there.  Qt is NOT installed correctly for the
>target build environment.
>
>...I, however, believe that Qt IS installed correctly.  I find
>QtCore4.lib
>in the said directory.  I tried to decipher the code found in
>FindQt4.cmake, but I don't know the cmake language.  "qmake -query
>QT_INSTALL_LIBS" does indeed report the directory named above, and it's
>full of Qt-licious libraries.
>
>Later on I see...
>
>Qt QTGUI library not found.
>Qt QTXML library not found.
>Qt QTCORE library not found.
>
>...and the ultimate wammy...
>
>CMake Error at ApiExtractor/CmakeLists.txt:82 (qt4_add_resources):
>Unknown
>CMake command "qt4_add_resources".
>
>So "shiboken" fails to configure.  But I'm hoping that the latter
>errors
>are just a symptom of the initial warning above indicating that, oddly,
>cmake can't locate my Qt libraries.
>
>I'm at a complete loss.  I've wasted an entire day here at work on this
>one
>issue.  Any help would be greatly appreciated.
>
>--Sp
>
>
>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] try_compile additional include FILES

[Hendrik Sattler]

Hi,

If you know that you are on Windows and know all that, why do you want an 
expensive check for it?

HS


Am 30. September 2016 19:57:07 MESZ, schrieb J Decker :
>I've been playing with libressl; which has quite a few
>'check_function_exists'
>
>In particular 'check-function-exists( inet_pton HAVE_INET_PTON )'
>
>this is failing, because, directly, there is no 'inet_pton' in windows,
>but
>by including ws2tcpip.h there is a #define that changes it to
>InetPton[A/W]
>
>but I don't see any way to specify additional files to include.
>
>
>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMake 3.6.0-rc4 now ready for testing!

[Hendrik Sattler]

Zitat von Brad King <brad.k...@kitware.com>:


On 06/29/2016 05:05 PM, Hendrik Sattler wrote:

* The "InstallRequiredSystemLibraries" module learned a new
 "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment
 of the Windows Universal CRT libraries with Visual Studio 2015.


Maybe the help should note that this is only needed when targeting
WindowsXP.


It is also useful for deploying to Windows 7 machines that have
not had updates installed to provide the UCRT libraries.  I've
updated the documentation to show Windows XP as an example:

 InstallRequiredSystemLibraries: Document UCRT option use case
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dab3ccf2


Thanks.


* A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for
 use by toolchain files to specify platform-specific variables that
 must be propagated by the "try_compile()" command into test
 projects.


Can someone please add an example to the help.


Done:

 Help: Document CMAKE_TRY_COMPILE_PLATFORM_VARIABLES example
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c05d240e


E.g. I tried to make the initial try_compile() to respect my
CMAKE_CXX_FLAGS_INIT variable that gets defined in my toolchain file...


CMAKE_CXX_FLAGS_INIT is not documented for use in a toolchain file.
It is used internally by platform modules.


I really have to use CXXFLAGS environment variable which feels clumsy.
It's that really the only reliable way to define compiler arguments
like -mcpu= for all compiler invocations?


It is one way.  Another way is to set the cache entry directly:

  set(CMAKE_CXX_FLAGS "-mcpu=..." CACHE STRING "C++ flags")

Note that CMAKE_CXX_FLAGS is propagated by try_compile automatically.
The above two approaches are actually just trying to get a toolchain
file to have a say in the initial CMAKE_CXX_FLAGS cache entry value
of the main project.


The the following code in CMakeCXXInformation.cmake does nothing
snip
# add the flags to the cache based
# on the initial values computed in the platform/*.cmake files
# use _INIT variables so that this only happens the first time
# and you can set these flags in the cmake cache
set(CMAKE_CXX_FLAGS_INIT "$ENV{CXXFLAGS} ${CMAKE_CXX_FLAGS_INIT}")
# avoid just having a space as the initial value for the cache
if(CMAKE_CXX_FLAGS_INIT STREQUAL " ")
  set(CMAKE_CXX_FLAGS_INIT)
endif()
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS_INIT}" CACHE STRING
 "Flags used by the compiler during all build types.")
snip

So each and every toolchain file shall also take care of the  
environment variable?
How about CMAKE_CXX_FLAGS_INIT set by other module files? Ok, only 3  
real users in CMake's module folder.


And VERY IMPORTANT: the toolchain file MUST make those variables CACHE  
variables, else it will not work (at least CMAKE_CXX_FLAGS is only  
propagated, then).


Thanks...

Hendrik



--

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] [ANNOUNCE] CMake 3.6.0-rc4 now ready for testing!

[Hendrik Sattler]

Am 29. Juni 2016 21:30:40 MESZ, schrieb Robert Maynard 
:
>I am proud to announce the fourth CMake 3.6 release candidate.
>
>Sources and binaries are available at:
>  https://cmake.org/download/
>
>Documentation is available at:
>  https://cmake.org/cmake/help/v3.6
>
>Release notes appear below and are also published at
>  https://cmake.org/cmake/help/v3.6/release/3.6.html
>
>Some of the more significant features of CMake 3.6 are:
>
>* The "Visual Studio 14 2015" generator learned to support the
>  Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This
>  feature is experimental.
>
>* The "list()" command gained a "FILTER" sub-command to filter list
>  elements by regular expression.

This would also be very handy for generator expressions, similar to JOIN.

>* A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally
>  tell the "try_compile()" command to build a static library instead
>  of an executable.  This is useful for cross-compiling toolchains
>  that cannot link binaries without custom flags or scripts.
>
>* A "_CLANG_TIDY" target property and supporting
>  "CMAKE__CLANG_TIDY" variable were introduced to tell the
>  Makefile Generators and the "Ninja" generator to run "clang-tidy"
>  along with the compiler for "C" and "CXX" languages.
>
>* The "ExternalProject" module leared the "GIT_SHALLOW 1" option to
>  perform a shallow clone of a Git repository.
>
>* The "ExternalProject" module learned to initialize Git submodules
>  recursively and also to initialize new submodules on updates.  Use
>  the "GIT_SUBMODULES" option to restrict which submodules are
>  initalized and updated.
>
>* The "InstallRequiredSystemLibraries" module learned a new
>  "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment
>  of the Windows Universal CRT libraries with Visual Studio 2015.
 
Maybe the help should note that this is only needed when targeting WindowsXP.

>* The "Compile Features" functionality is now aware of features
>  supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX
>  platforms.
>
>Deprecated and Removed Features
>===
>
>* The "CMakeForceCompiler" module and its macros are now deprecated.
>  See module documentation for an explanation.
>
>* The "Visual Studio 7 .NET 2003" generator is now deprecated and
>  will be removed in a future version of CMake.
>
>* The "Visual Studio 7" generator (for VS .NET 2002) has been
>  removed. It had been deprecated since CMake 3.3.
>
>* The "Visual Studio 6" generator has been removed. It had been
>  deprecated since CMake 3.3.
>
>
>
>CMake 3.6 Release Notes
>***
>
>Changes made since CMake 3.5 include the following.
>
>
>New Features
>
>
>
>Generators
>--
>
>* The "Ninja" generator learned to produce phony targets of the form
>  "sub/dir/all" to drive the build of a subdirectory. This is
>  equivalent to "cd sub/dir; make all" with Makefile Generators.
>
>* The "Ninja" generator now includes system header files in build
>  dependencies to ensure correct re-builds when system packages are
>  updated.
>
>* The "Visual Studio 14 2015" generator learned to support the
>  Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This
>  feature is experimental.
>
>
>Commands
>
>
>* The "add_custom_command()" and "add_custom_target()" commands
>  learned how to use the "CROSSCOMPILING_EMULATOR" executable target
>  property.
>
>* The "install()" command learned a new "EXCLUDE_FROM_ALL" option to
>  leave installation rules out of the default installation.
>
>* The "list()" command gained a "FILTER" sub-command to filter list
>  elements by regular expression.
>
>* The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained
>  support for the "%s" placeholder.  This is the number of seconds
>  since the UNIX Epoch.
>
>
>Variables
>-
>
>* A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell
>  Makefile Generators to limit dependency scanning only to files in
>  the project source and build trees.
>
>* A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate
>  when CMake is running on an Oracle Solaris host.
>
>* A "CMAKE__STANDARD_INCLUDE_DIRECTORIES" variable was added
>  for use by toolchain files to specify system include directories to
>  be appended to all compiler command lines.
>
>* The "CMAKE__STANDARD_LIBRARIES" variable is now documented.
>  It is intended for use by toolchain files to specify system
>  libraries to be added to all linker command lines.
>
>* A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell
>  the "Ninja" generator to configure the generated "build.ninja" file
>  for use as a "subninja".
>
>* A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for
>  use by toolchain files to specify platform-specific variables that
>  must be propagated by the "try_compile()" command into test
>  projects.

Can someone please add an example to the 

Re: [CMake] [Visual Studio] Is it possible to specify a different target architecture?

[Hendrik Sattler]

Hi,

Yes, it is possible.
Generate the solution for Visual Studio 11 2012 and open it in VS2015. VS will 
ask you once if to convert the project and you say no. Done.

HS


Am 28. Juni 2016 15:51:47 MESZ, schrieb Adam Rankin :
>Hello all,
>
>I am wondering if there exist CMake commands/variables to specify for
>Visual Studio to have the project file(s) generated target a different
>architecture than the one associated with that version of Visual
>Studio.
>
>For example, I develop in VS2015, but would like to target the VS2012
>redistributable (v110).
>
>Is this possible?
>
>Kind regards,
>Adam
>
>
>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] VS2015 and toolset v110

[Hendrik Sattler]

To generate for V110 toolset, you can just use visual studio 11 generator and 
open the result in VS14.

HS


Am 21. Juni 2016 16:28:36 MESZ, schrieb Lars :
>Hello,
> 
>Environment is Windows 7sp1, CMake 3.5.2 and Visual Studio 2015 Pro.
> 
>Running below command in MSBuild Command prompt for VS2015 shell;
>cmake -DCMAKE_BUILD_TYPE=Release -G "Visual Studio 14 2015" -T v110
>../src
> 
>output is;
>The c compiler identification is unknown
>The cxx compiler identification is unknown
>No CMAKE_C_COMPILER could be found
>No CMAKE_CXX_COMPILER could be found
> 
>Updating command with different toolset (same shell)
>cmake -DCMAKE_BUILD_TYPE=Release -G "Visual Studio 14 2015" -T v140
>../src
> 
>output is;
>The c compiler identification is MSVC 19.0.23..
>The cxx compiler identification is MSVC 19.0.23..
>check for working c compiler using Visual Studio 14 2015
>check for working c compiler using Visual Studio 14 2015 -- works
> 
>Using toolset v140 appears to find the compiler but using v100 or v110
>or vs120 does not work. Why is this happening?
> 
>The second example using v140 actually also fails but that is because
>it is trying to find boost_math_c99_v140 library which does not exists
>(we use v110 library).
> 
>(and no, I cannot change toolset at the moment)
> 
>Kind regards, Lars
> 
>
>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later.

[Hendrik Sattler]

Am 1. Juni 2016 09:26:18 MESZ, schrieb Jakob van Bethlehem 
<jsvanbethle...@gmail.com>:
>That is what he said, but it seems to be a typo, because the
>CMakeLists.txt
>file clearly states 'set(QT_DIR
>${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)'

Ok, I overlooked that one...

>- still a stone-age version of Qt actually :(

Hey, that was the LTS release until 1 or 2 month ago!
And they made Qt 5.6 an LTS release also to quieten people that complain about 
dropping modules without proper replacement (means feature parity) and dropping 
compiler support.
You will see users of Qt 5.6 for a loong time.

>On Wed, Jun 1, 2016 at 9:09 AM, Hendrik Sattler
><p...@hendrik-sattler.de>
>wrote:
>
>>
>>
>> Am 1. Juni 2016 09:02:41 MESZ, schrieb Jakob van Bethlehem <
>> jsvanbethle...@gmail.com>:
>> >Hej,
>> >
>> >Some things that come to mind:
>> >* You're generating files *inside* the source tree - you're not
>> >supposed to
>> >do that
>> >* Why do you want to have a special Qt_tmp directory? I don't see
>the
>> >benefit, and without that requirement you can simply use the
>> >qt4_wrap_cpp
>> >macro explicitly and you still are not forced to use the automoc
>> >feature
>> >
>> >And now for what is probably wrong in your CMakeLists.txt:
>> >* It seems you made an important mistake regarding the behaviour of
>> >'file(GLOB)'. That function will do the expansion *while running
>> >CMake*.
>> >But at that time the moc_* files *don't exist!* (as a matter of
>fact,
>> >the
>> >tmp directory doesn't even exist). In other words, your
>${Moc_SOURCES}
>> >will
>> >be empty, and hence they are not compiled, and hence you get
>precisely
>> >the
>> >linker errors you see (because these sources implement the functions
>> >that
>> >are listed as missing by the linker)
>> >
>> >If you would use the qt4_wrap_cpp() macro you don't run into this
>> >problem,
>> >so I'd strongly suggest using it.
>>
>> Except that he is using Qt3.
>>
>> >Sincerely,
>> >Jakob van Bethlehem
>> >
>> >
>> >
>> >
>> >On Tue, May 31, 2016 at 4:52 PM, irene w <ire866...@gmail.com>
>wrote:
>> >
>> >> It seems CMakw could not find the generated moc_xxx files.  I
>> >modified the
>> >> scripts to specify moc_xxx files is generated, but it still has
>same
>> >errors.
>> >>
>> >> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp
>> >>  COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
>> >> ${Qt_tmp}/moc_GMWindow.cpp
>> >>  DEPENDS ${GM_DIR}/GMWindow.h
>> >>)
>> >> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp)
>> >> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES
>> >> GENERATED 1)
>> >> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY
>> >OBJECT_DEPENDS
>> >> ${Qt_tmp}/moc_GMWindow.cpp)
>> >>
>> >> .
>> >> add_dependencies (GM generate_foo)
>> >>
>> >>
>> >> Does the Macro  "SET_SOURCE_FILES_PROPERTIES" with "GENERATED"
>> >> setting work for this purposes?  Any help would be greatly
>> >appreciated !
>> >>
>> >>
>> >> On Wed, May 25, 2016 at 12:48 PM, irene w <ire866...@gmail.com>
>> >wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> I am compiling a simple Qt3 application on Linux using CMake. In
>my
>> >case,
>> >>> I need to build moc_xxx files with custom options and output to a
>> >specified
>> >>> directory, So, I was not using CAMKE_AUTO macros. My cmake
>scripts
>> >create a
>> >>> "Qt_tmp" directory and output moc_xxx there.
>> >>>
>> >>> It looked it always failed to link the moc_xxx files for the
>first
>> >time
>> >>> build when there is no "Qt_tmp" directory, and succeeded if I ran
>> >build
>> >>> again if the "Qt_tmp" directory and moc_xxx files created by the
>> >failed
>> >>> build were kept without removing.  However, it'll fail if I
>delete
>> >>> the "Qt_tmp" directory.
>> >>>
>> >>> Even it failed at the first build,

Re: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later.

[Hendrik Sattler]

Am 1. Juni 2016 09:02:41 MESZ, schrieb Jakob van Bethlehem 
:
>Hej,
>
>Some things that come to mind:
>* You're generating files *inside* the source tree - you're not
>supposed to
>do that
>* Why do you want to have a special Qt_tmp directory? I don't see the
>benefit, and without that requirement you can simply use the
>qt4_wrap_cpp
>macro explicitly and you still are not forced to use the automoc
>feature
>
>And now for what is probably wrong in your CMakeLists.txt:
>* It seems you made an important mistake regarding the behaviour of
>'file(GLOB)'. That function will do the expansion *while running
>CMake*.
>But at that time the moc_* files *don't exist!* (as a matter of fact,
>the
>tmp directory doesn't even exist). In other words, your ${Moc_SOURCES}
>will
>be empty, and hence they are not compiled, and hence you get precisely
>the
>linker errors you see (because these sources implement the functions
>that
>are listed as missing by the linker)
>
>If you would use the qt4_wrap_cpp() macro you don't run into this
>problem,
>so I'd strongly suggest using it.

Except that he is using Qt3.

>Sincerely,
>Jakob van Bethlehem
>
>
>
>
>On Tue, May 31, 2016 at 4:52 PM, irene w  wrote:
>
>> It seems CMakw could not find the generated moc_xxx files.  I
>modified the
>> scripts to specify moc_xxx files is generated, but it still has same
>errors.
>>
>> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp
>>  COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
>> ${Qt_tmp}/moc_GMWindow.cpp
>>  DEPENDS ${GM_DIR}/GMWindow.h
>>)
>> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp)
>> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES
>> GENERATED 1)
>> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY
>OBJECT_DEPENDS
>> ${Qt_tmp}/moc_GMWindow.cpp)
>>
>> .
>> add_dependencies (GM generate_foo)
>>
>>
>> Does the Macro  "SET_SOURCE_FILES_PROPERTIES" with "GENERATED"
>> setting work for this purposes?  Any help would be greatly
>appreciated !
>>
>>
>> On Wed, May 25, 2016 at 12:48 PM, irene w 
>wrote:
>>
>>> Hi,
>>>
>>> I am compiling a simple Qt3 application on Linux using CMake. In my
>case,
>>> I need to build moc_xxx files with custom options and output to a
>specified
>>> directory, So, I was not using CAMKE_AUTO macros. My cmake scripts
>create a
>>> "Qt_tmp" directory and output moc_xxx there.
>>>
>>> It looked it always failed to link the moc_xxx files for the first
>time
>>> build when there is no "Qt_tmp" directory, and succeeded if I ran
>build
>>> again if the "Qt_tmp" directory and moc_xxx files created by the
>failed
>>> build were kept without removing.  However, it'll fail if I delete
>>> the "Qt_tmp" directory.
>>>
>>> Even it failed at the first build, the moc_xxx files were
>>> successfully created in the "Qt_tmp" directory.
>>>
>>> Here is my cmake scripts and the errors I got.  Can anyone help me
>to
>>> figure out the issues? Any help would be greatly appreciated. 
>Thanks.
>>>
>>> CMakeLists.txt
>>>
>>>
>-
>>> cmake_minimum_required(VERSION 3.4.1)
>>> project (GM_Application CXX)
>>> SET (CMAKE_SYSTEM_NAME Linux)
>>> SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++)
>>> set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR})
>>> set (QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)
>>> LINK_DIRECTORIES (${QT_DIR}/lib)
>>> INCLUDE_DIRECTORIES ("${QT_DIR}/include"
>>>  "${GM_DIR}"
>>> )
>>> # Compiling QT moc and ui  #
>>> set (QT_MOC_CMD ${QT_DIR}/bin/moc -I$(QT_DIR)/mkspecs/linux-g++
>>> -I${QT_DIR}/include -I${QT_DIR}/include/QtGui)
>>> file (MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp)
>>> set (Qt_tmp ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp)
>>> add_custom_target (Moc_GMWindows
>>>COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
>>> ${Qt_tmp}/moc_GMWindow.cpp
>>>   )
>>>
>>> # Compiling application  #
>>> file (GLOB GM_SOURCES ${GM_DIR}/*.h ${GM_DIR}/*.cpp)
>>> file (GLOB Moc_SOURCES ${Qt_tmp}/*.h ${Qt_tmp}/*.cpp)
>>> add_executable (GM ${GM_SOURCES} ${Moc_SOURCES})
>>> target_include_directories (GM PRIVATE ${Qt_tmp})
>>> add_dependencies (GM Moc_GMWindows)
>>> target_link_libraries (GM QtGui)
>>>
>>>
>>>
>---
>>> Errors:
>>>
>>> Scanning dependencies of target Moc_GMWindows
>>> [  0%] Built target Moc_GMWindows
>>> Scanning dependencies of target GM
>>> [ 14%] Building CXX object GM/CMakeFiles/GM.dir/GM/GM.cpp.o
>>> [ 42%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMService.cpp.o
>>> [ 67%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMWindow.cpp.o
>>> [ 85%] Building CXX object GM/CMakeFiles/GM.dir/GM/main.cpp.o
>>> [100%] Linking CXX executable ../bin/GM
>>> 

Re: [CMake] Cross Compilation & Source file generators

[Hendrik Sattler]

Hi,

Did you read the Wiki page about cross compiling with CMake? CMake can already 
restrict searching for libraries to certain directories when cross compiling.

HS


Am 21. Mai 2016 04:13:38 MESZ, schrieb Walter Gray :
>A small addendum - The way I am currently solving this problem is by
>replacing the version of protoc in the library folder for android with
>one
>that works on the host machine, but this is really not the best since
>it
>means that the library distribution is tied to the host AND the target.
>
>Thinking in terms of concepts, I think I would want a find_package that
>understood the difference between finding a package for executing and
>finding a package for linking, but that'd be a pretty fundamental
>change.
>
>On Fri, May 20, 2016 at 7:02 PM Walter Gray 
>wrote:
>
>> I've got a project with a number of target platforms, including some
>that
>> I have to cross-compile to such as android, that uses protobuf. If
>you're
>> unfamiliar, the crux of the issue is that there is both a library,
>> libprotobuf, and an 'compiler', protoc, that takes .proto files and
>> generates a .h/.cc pair that are then included in the project.
>>
>> When cross compiling, want to use the libprotobuf that was compiled
>on
>> andriod, but the protoc that was compiled for my host environment.
>How
>> could this be achieved?
>>
>> Currently, my build machine has several different directories where I
>> store the external libraries that have been compiled for the various
>> platforms/compilers that we support (Libraries-arm32, Libraries-x64,
>> Libraries-x64-vc14, ect).
>>
>> Solutions that require modifying protobuf's -config.cmake file are
>> welcome, I've already submitted several PR's improving it. I'd like
>to
>> establish what the best practice for this kind of situation is as I
>have
>> the same issue with Flatbuffers.
>>
>> On a slightly unrelated note, is there some way to write something
>like
>> the AUTOUIC system without modifying cmake itself? It would be lovely
>if
>> all I had to do was include the .proto file in the source file list.
>>
>> Thanks!
>> Walter
>>
>
>
>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] AUTOMOC with files on different folders

[Hendrik Sattler]

Am 12. Mai 2016 00:00:12 MESZ, schrieb Tiago Macarios :
>Hi Attila,
>
>Thank you for your help. You are right, if I apply the following
>modifications it works indeed:
>
>set( proj_HEADER
>include/a.h
>)
>
>add_library(proj SHARED ${proj_SOURCE} ${proj_HEADER})
>
>But now I got a second question. Why is adding the header files
>necessary?
>(Sorry the possibly naive question)
>
>I thought that adding the header files to the target was an
>anti-pattern (
>http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/
>). Is it related to moc generating header files during the build? If so
>why
>is it not a problem when everything is on the same folder?

That same page has a Errata section at the end. 

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Fwd: CPack does not generate a RPM

[Hendrik Sattler]

Am 17. April 2016 21:21:01 MESZ, schrieb Domen Vrankar 
:
>I've finally had time to look into this.
>
>The problem is that rpm expects a shared library to have execute
>permissions - during packaging missing execute permissions are ignored
>so dependency is found but once we try to install the package it
>figures out that it's missing hence the odd missing dependency error.
>
>To fix this simply set permissions that you want e.g.:
>
>set(LIBRARIES
>${LIB}/liblibrary.so
>${LIB}/liblibrary.so.5
>${LIB}/liblibrary.so.5.6.7)
>install(FILES ${LIBRARIES} DESTINATION lib
>  PERMISSIONS OWNER_EXECUTE # this permission is mandatory or package
>installation will fail
>)
>
>See the entire list of permissions here:
>https://cmake.org/cmake/help/v3.5/command/install.html
>
>I'll try to add some simple checking for such errors in CPack/RPM.

Actually the exec bit for library files is plain wrong. That RPM wrongly needs 
this is a bug in RPM. CMake should not make the world worse by making build 
systems set this exec bit on libraries. Just SILENTLY fix it up when generating 
the .rpm

Simple check: what happens when you try to execute the library from the command 
line? Only those files that have a defined behavior when running them should 
have the exec bit set.

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Creating a list of link directories from a variable

[Hendrik Sattler]

Hi,

yes, exactly. The easiest way to find out is to simply try it. The linker will 
tell you if some symbols need to be resolved. Static libraries are not linked 
but only compiled, so the application or library that links to such a static 
library must do this step.

If that library you use would use some established method like pkg-config  to 
expose those values, it would be much easier (if used correctly by the library 
author). It can differentiate between those cases.

HS


Am 1. April 2016 18:25:46 MESZ, schrieb "Salazar De Troya, Miguel" 
<salazardet...@llnl.gov>:
>Hello
>
>Thanks for your response. Is there automatic way to know which
>libraries my executable will need and which ones it won’t? Why is this
>the case for only shared libraries? Is it because the linking symbols
>are already in that shared library and I don’t need to link them again
>if I’m not using them directly?
>
>Miguel
>From: Hendrik Sattler
><p...@hendrik-sattler.de<mailto:p...@hendrik-sattler.de>>
>Date: Thursday, March 31, 2016 at 10:27 PM
>To: Miguel Salazar
><salazardet...@llnl.gov<mailto:salazardet...@llnl.gov>>,
>"cmake@cmake.org<mailto:cmake@cmake.org>"
><cmake@cmake.org<mailto:cmake@cmake.org>>
>Subject: Re: [CMake] Creating a list of link directories from a
>variable
>
>Hi,
>
>If the library is a shared object, try to NOT use all those libraries.
>If they are used in the library but are not part of its public API, you
>most likely don't need to link them. If you have no missing symbols
>when linking, you can avoid overlinking you program.
>
>If this is a static library, you have a lot more work. For each library
>without -l, use find_library() and use the library dirs as hints. Do
>NOT use link_directories().
>
>HS
>
>
>
>
>Am 1. April 2016 00:22:09 MESZ, schrieb "Salazar De Troya, Miguel"
><salazardet...@llnl.gov<mailto:salazardet...@llnl.gov>>:
>Hello
>
>I am trying to compile a program with a library that provides a bash
>script to generate the dependencies, libraries and the link directories
>for the Makefile. I want to generate a CMakeLists.txt that can handle
>these dependencies from that library. I have been able to come up with
>regexp that can extract the information and put it into a variable with
>the dirs or library names separated by comma, for instance:
>
>INCLUDE_DIRS =
>
>/g/g92/miguel/code/libmesh_2D/include;/usr/include/curl;/usr/include/glpk;/usr/local/tools/vtk-6.1.0/include/vtk-6.1;/g/g92/miguel/petsc-3.6.2/include;/g/g92/miguel/petsc-3.6.2/miguel-opt/include;/usr/local/tools/openmpi-intel-1.8.4/include/openmpi/opal/mca/hwloc/hwloc191/hwloc/include;/usr/local/tools/openmpi-intel-1.8.4/include/openmpi/opal/mca/event/libevent2021/libevent;/usr/local/tools/openmpi-intel-1.8.4/include/openmpi/opal/mca/event/libevent2021/libevent/include;/usr/local/tools/openmpi-intel-1.8.4/include;/usr/local/tools/openmpi-intel-1.8.4/include/openmpi;/usr/local/tools/boost-mpi-1.55.0//include
>
>
>LIBS =
>
>-lcurl;-lhdf5;-lglpk;-lvtkIOCore-6.1;-lvtkCommonCore-6.1;-lvtkCommonDataModel-6.1;-lvtkFiltersCore-6.1;-lvtkIOXML-6.1;-lvtkImagingCore-6.1;-lvtkIOImage-6.1;-lvtkImagingMath-6.1;-lz;-lpetsc;-lcmumps;-ldmumps;-lsmumps;-lzmumps;-lmumps_common;-lpord;-lscalapack;-lHYPRE;-lml;-llapack;-lblas;-lparmetis;-lmetis;-lX11;-lhwloc;-lssl;-lcrypto;-lmpi_usempif08;-lmpi_usempi_ignore_tkr;-lmpi_mpifh;-lifport;-lifcore;-lm;-lmpi;-limf;-lsvml;-lirng;-lipgo;-ldecimal;-lcilkrts;-lstdc++;-lgcc_s;-lirc;-lpthread;-lirc_s;-ldl;-lmesh_opt
>
>
>LIB_DIRS =
>
>/usr/lib;/lib;/usr/lib64;/usr/local/tools/vtk-6.1.0/lib;/g/g92/miguel/petsc-3.6.2/miguel-opt/lib;/usr/local/tools/openmpi-intel-1.8.4/lib;/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64;/usr/lib/gcc/x86_64-redhat-linux/4.4.7;/g/g92/miguel/code/libmesh_2D/lib
>
>
>These are variables in my environment that I use in CMake with
>$ENV{VAR}. How can I use this information for the commands:
>
>include_directories($ENV{INCLUDE_DIRS})
>
>link_directories($ENV{LIB_DIRS})
>
>target_link_libraries($ENV{LIBS}) ?
>
>
>It seems that cmake can digest the include directories and the
>target_link_libraries (because they appear correctly in the
>compilation), but not the link_directories. Why? Also, I’ve read that
>it is more correct to use find_library() instead. How would I iterate
>over the LIBS? Can I use a single LIB_DIRS (with all the information
>above) in the PATHS argument of find_library()
>
>
>Thanks
>
>Miguel
>
>--
>
>Powered by
>http://secure-web.cisco.com/1SkTeDpqcSTqs7V0Q2yjUdQEsQ1huaYLleRl_DSB40mZrJmSB4Lr6utBlMnP2n8teBgjMf-JqbxyEzxRwI33xdCPfZ4V-R2

Re: [CMake] Creating a list of link directories from a variable

[Hendrik Sattler]

Hi,

If the library is a shared object, try to NOT use all those libraries. If they 
are used in the library but are not part of its public API, you most likely 
don't need to link them. If you have no missing symbols when linking, you can 
avoid overlinking you program.

If this is a static library, you have a lot more work. For each library without 
-l, use find_library() and use the library dirs as hints. Do NOT use 
link_directories().

HS




Am 1. April 2016 00:22:09 MESZ, schrieb "Salazar De Troya, Miguel" 
:
>Hello
>
>I am trying to compile a program with a library that provides a bash
>script to generate the dependencies, libraries and the link directories
>for the Makefile. I want to generate a CMakeLists.txt that can handle
>these dependencies from that library. I have been able to come up with
>regexp that can extract the information and put it into a variable with
>the dirs or library names separated by comma, for instance:
>
>INCLUDE_DIRS =
>
>/g/g92/miguel/code/libmesh_2D/include;/usr/include/curl;/usr/include/glpk;/usr/local/tools/vtk-6.1.0/include/vtk-6.1;/g/g92/miguel/petsc-3.6.2/include;/g/g92/miguel/petsc-3.6.2/miguel-opt/include;/usr/local/tools/openmpi-intel-1.8.4/include/openmpi/opal/mca/hwloc/hwloc191/hwloc/include;/usr/local/tools/openmpi-intel-1.8.4/include/openmpi/opal/mca/event/libevent2021/libevent;/usr/local/tools/openmpi-intel-1.8.4/include/openmpi/opal/mca/event/libevent2021/libevent/include;/usr/local/tools/openmpi-intel-1.8.4/include;/usr/local/tools/openmpi-intel-1.8.4/include/openmpi;/usr/local/tools/boost-mpi-1.55.0//include
>
>
>LIBS =
>
>-lcurl;-lhdf5;-lglpk;-lvtkIOCore-6.1;-lvtkCommonCore-6.1;-lvtkCommonDataModel-6.1;-lvtkFiltersCore-6.1;-lvtkIOXML-6.1;-lvtkImagingCore-6.1;-lvtkIOImage-6.1;-lvtkImagingMath-6.1;-lz;-lpetsc;-lcmumps;-ldmumps;-lsmumps;-lzmumps;-lmumps_common;-lpord;-lscalapack;-lHYPRE;-lml;-llapack;-lblas;-lparmetis;-lmetis;-lX11;-lhwloc;-lssl;-lcrypto;-lmpi_usempif08;-lmpi_usempi_ignore_tkr;-lmpi_mpifh;-lifport;-lifcore;-lm;-lmpi;-limf;-lsvml;-lirng;-lipgo;-ldecimal;-lcilkrts;-lstdc++;-lgcc_s;-lirc;-lpthread;-lirc_s;-ldl;-lmesh_opt
>
>
>LIB_DIRS =
>
>/usr/lib;/lib;/usr/lib64;/usr/local/tools/vtk-6.1.0/lib;/g/g92/miguel/petsc-3.6.2/miguel-opt/lib;/usr/local/tools/openmpi-intel-1.8.4/lib;/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64;/usr/lib/gcc/x86_64-redhat-linux/4.4.7;/g/g92/miguel/code/libmesh_2D/lib
>
>
>These are variables in my environment that I use in CMake with
>$ENV{VAR}. How can I use this information for the commands:
>
>include_directories($ENV{INCLUDE_DIRS})
>
>link_directories($ENV{LIB_DIRS})
>
>target_link_libraries($ENV{LIBS}) ?
>
>
>It seems that cmake can digest the include directories and the
>target_link_libraries (because they appear correctly in the
>compilation), but not the link_directories. Why? Also, I’ve read that
>it is more correct to use find_library() instead. How would I iterate
>over the LIBS? Can I use a single LIB_DIRS (with all the information
>above) in the PATHS argument of find_library()
>
>
>Thanks
>
>Miguel
>
>
>
>
>-- 
>
>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:
>http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Two phase install?

[Hendrik Sattler]

Am 24. März 2016 10:14:40 MEZ, schrieb "Alan W. Irwin" 
:
>On 2016-03-24 03:59- Scott Aron Bloom wrote:
>
>> That method does NOT work with windows...  And since the visual
>studio project has the external as a single command, (not sure if its
>calling nmake or the new build cmd) the proeject is not run in
>parallel.
>
>I am pretty sure ExternalProject_Add only works with generators
>associated with build commands you can run from the command line such
>as make, nmake, jom, ninja, etc..  So, for MSVC the way you arrange
>that is
>avoid all the visual studio generators, and instead use one of
>"NMake Makefiles", "NMake Makefiles JOM", or "Ninja".

No. Just as with cmake-generated solutions, you can build those on the command 
line using msbuild or devenv, the one used by cmake depends on the cmake 
version. You can even use cmake itself to trigger the right build command for 
those. Parallel building must be enabled by hand when using msbuild. For 
devenv, the setting from the IDE is used.

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Building with Cmake using Boost problem

[Hendrik Sattler]

Am 16. März 2016 22:13:14 MEZ, schrieb Karel Geiregat :

>According to the cmake documentation of FindBoost
> you have to
>name
>the required libraries as described;
>
>"date_time" for "libboost_date_time"

You do NOT have to rename any files! Doing so completely defeats the purpose of 
a find module.

Additionally, .lib files for Microsoft compilers do NOT start like libxxx.lib 
but only xxx.lib
Building boost with your compiler should give you the right files as-is.

Why are you reading documentation of cmake 3.0 when using cmake 3.5? I cannot 
find anything in the documentation of the boost find module about renaming.
However it documents steps to debug problems.

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Calling a Python Testing Script from CMake/CTest

[Hendrik Sattler]

It actually should be used using find_package()

HS


Am 24. Februar 2016 16:10:49 MEZ, schrieb George Ryan 
:
>Thanks, Matthew. That worked.
>
>I had tried something similar using find(PythonInterp REQUIRED), but
>that didn't work. The include() worked perfectly!
>
>Thanks!
>George
>
>
>On 02/24/2016 10:51 AM, Matthew Keeler wrote:
>My guess is that the command prompt is seeing the .py extension and
>automatically invoking the python interpreter for you. On other
>platforms it looks for the #!/usr/bin/env python which won’t work on
>windows.What you should do is use the FindPythonInterp cmake module to
>find your python executable and specify the interpreter to execute in
>your add test line.
>https://cmake.org/cmake/help/v3.3/module/FindPythonInterp.html
>
>Something like the following should work (I have not tested so the
>syntax might need some slight tweaks).
>
>include(FindPythonInterp)
>add_test(NAME sample_test COMMAND ${PYTHON_EXECUTABLE}
>${CMAKE_CURRENT_SOURCE_DIR}/sample_test.py WORKING_DIRECTORY
>${EXECUTABLE_OUTPUT_PATH} )
>
>--
>Matthew Keeler
>
>On February 24, 2016 at 09:15:10, George Ryan
>(george.r...@geospectrum.ca) wrote:
>
>Hi,
>
>I am having difficulty getting a python script to run a C++ subprocess
>on Window 7 using VS2013. On Linux, the following code works fine, but
>on Windows, from the command line I get the following output:
>
>Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
>Copyright (C) Microsoft Corporation. All rights reserved.
>
>Running tests...
>Test project C:/work/s/sandbox/ctestpy/b
>Start 1: sample_test
>1/1 Test #1: sample_test ..***Not Run 0.00 sec
>
>0% tests passed, 1 tests failed out of 1
>
>Total Test time (real) = 0.06 sec
>
>The following tests FAILED:
>1 - sample_test (BAD_COMMAND)
>Errors while running CTest
>NMAKE : fatal error U1077: 'echo' : return code '0x8'
>Stop.
>
>No matter what options I supply to ctest, I can't seem to get any
>additional insight. I am assuming that for some reason the
>WORKING_DIRECTORY isn't being obeyed on Windows?
>
>If I run the python script manually from the command prompt, it works
>fine. The python executable is in my $PATH.On Linux I am using CMake
>3.3.1, and on Windows I have CMake 3.2.3.
>
>
>
>sample.cpp
>
>int main()
>{
>return 0;
>}
>
>--
>
>sample_test.py
>
>#!/usr/bin/env python
>import sys
>import subprocess
>
>sample = subprocess.Popen("./sample")
>sample.wait()
>if sample.returncode != 0:
>sys.exit(1)
>else:
>sys.exit(0)
>~
>
>
>CMakeLists.txt
>
>cmake_minimum_required(VERSION 3.0)
>project(sampleprg)
>
>enable_testing()
>
>add_executable( sample sample.cpp )
>
>add_test(NAME sample_test
>COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/sample_test.py
>WORKING_DIRECTORY ${EXECUTABLE_OUTPUT_PATH} )
>
>
>
>
>--
>
>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:
>http://public.kitware.com/mailman/listinfo/cmake
>
>
>--
>Senior Software Architect
>GeoSpectrum Technologies Inc.
>Dartmouth, Nova Scotia, Canada
>
>
>
>
>-- 
>
>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:
>http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Calling a Python Testing Script from CMake/CTest

[Hendrik Sattler]

Am 24. Februar 2016 15:09:47 MEZ, schrieb George Ryan 
:
>Hi,
>
>I am having difficulty getting a python script to run a C++ subprocess
>on Window 7 using VS2013. On Linux, the following code works fine, but
>on Windows, from the command line I get the following output:
>
>Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
>Copyright (C) Microsoft Corporation.  All rights reserved.
>
>Running tests...
>Test project C:/work/s/sandbox/ctestpy/b
>Start 1: sample_test
>1/1 Test #1: sample_test ..***Not Run   0.00 sec
>
>0% tests passed, 1 tests failed out of 1
>
>Total Test time (real) =   0.06 sec
>
>The following tests FAILED:
>  1 - sample_test (BAD_COMMAND)
>Errors while running CTest
>NMAKE : fatal error U1077: 'echo' : return code '0x8'
>Stop.
>
>No matter what options I supply to ctest, I can't seem to get any
>additional insight. I am assuming that for some reason the
>WORKING_DIRECTORY isn't being obeyed on Windows?
>
>If I run the python script manually from the command prompt, it works
>fine. The python executable is in my $PATH.On Linux I am using CMake
>3.3.1, and on Windows I have CMake 3.2.3.
>
>
>
>sample.cpp
>
>int main()
>{
>  return 0;
>}
>
>--
>
>sample_test.py
>
>#!/usr/bin/env python
>import sys
>import subprocess
>
>sample = subprocess.Popen("./sample")
>sample.wait()
>if sample.returncode != 0:
>sys.exit(1)
>else:
>sys.exit(0)
>~
>
>
>CMakeLists.txt
>
>cmake_minimum_required(VERSION 3.0)
>project(sampleprg)
>
>enable_testing()
>
>add_executable( sample sample.cpp )
>
>add_test(NAME sample_test
> COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/sample_test.py
> WORKING_DIRECTORY ${EXECUTABLE_OUTPUT_PATH} )

You have to manuall call python with the script as argument. Shebang lines 
don't work on Windows.

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Can't get CMake to use an import library generated from a MODULE target

[Hendrik Sattler]

Am 18. Februar 2016 09:44:35 MEZ, schrieb Sam Habiel :
>Rather than email one of the folks at Kitware, I decided to join the
>CMake mailing list... Hello all for those who remember me.
>
>I apologize for the long email.
>
>A few of us have been trying to port GT.M
>(https://www.fisglobal.com/Solutions/Services/Database-Engine) to
>Cygwin, 1. to get it running on Windows 2. as an exercise to prepare
>for harder ports, the Raspberry Pi being the holy grail here. That's
>the background.

And then you try Cygwin? That's about as close to Rasberry Pi on Linux as bare 
Windows itself. Especially your problem from below is only caused by Windows.

>The problem we are having is familiar to many; but not initially to
>me. See the heading "Shared libraries with Windows/MinGW" in this
>article:
>http://gernotklingler.com/blog/creating-using-shared-libraries-different-compilers-different-operating-systems/.
>
>CMakeLists.txt:
>https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt
>
>The error:
>[ 88%] Linking C shared module plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o:
>In function `gc_load_gtmshr_symbols':
>/home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:100: undefined
>reference to `gtm_malloc'
>/home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:101: undefined
>reference to `gtm_free'
>collect2: error: ld returned 1 exit status
>CMakeFiles

Looking at these locations, it is clear that you store a reference to a 
function, there. The reference cannot be resolved but for a Windows DLL all 
references must be resolved at link time.

/libgtmcrypt_gcrypt_AES256CFB.so.dir/build.make:202: recipe
>for target 'plugin/cyggtmcrypt_gcrypt_AES256CFB.dll' failed
>make[2]: *** [plugin/cyggtmcrypt_gcrypt_AES256CFB.dll] Error 1
>CMakeFiles/Makefile2:891: recipe for target
>'CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all' failed
>make[1]: *** [CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all] Error
>2
>Makefile:116: recipe for target 'all' failed
>make: *** [all] Error 2
>
>Here's the link command (I turned CMAKE_VERBOSE_MAKEFILE=ON):
>/usr/bin/cc   -march=i586 -fsigned-char -Wmissing-prototypes
>-Wreturn-type -Wpointer-sign -fno-omit-frame-pointer -g -DDEBUG
>-shared -Wl,--enable-auto-import -o
>plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
>-Wl,--major-image-version,0,--minor-image-version,0
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_ref.c.o
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_pk_ref.c.o
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_dbk_ref.c.o
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_sym_ref.c.o
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o
>-lgpg-error -lgpgme -lgcrypt /usr/local/lib/libconfig.dll.a
>
>What is missing is that there needs to be either a link to
>cyggtmshr.dll, or a way for CMake to know to generate a
>libgtmshr_import.lib and add it to the link command.
 
Or don't use a direct reference in the code but use the module that provides 
those functions at runtime like you designed it to. You can use local wrapper 
functions to do so.

>So here is what I tried:
>1. Using the GenerateExportHeader functionality of CMake on libgtmshr.
>If I do that, it doesn't seem to generate the import library; but it
>sure does generate an export header, which I don't need. Here it is:
>include(GenerateExportHeader)
>generate_export_header(libgtmshr
>BASE_NAME libgtmshr
>EXPORT_MACRO_NAME libgtmshr_EXPORTS
>EXPORT_FILE_NAME  libgtmshr_EXPORTS.h
>STATIC_DEFINE SHARED_EXPORTS_BUILT_AS_STATIC)
>
>2. Explicitly adding a libgtmshr as a dependency on line
>https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt#L531,
>but only for Cygwin. I get this error message:
>CMake Error at CMakeLists.txt:542 (target_link_libraries):
>Target "libgtmshr" of type MODULE_LIBRARY may not be linked into
>another
>target.  One may link only to STATIC or SHARED libraries, or to
>executables
>  with the ENABLE_EXPORTS property set.
>
>The GT.M developer familiar with CMake suggested me to use LINK_FLAGS
>and have CMake use the file by us hardcoding it in; which I am okay
>doing, but I thought I would check to see if there is an alternative
>way of doing this.
>
>I also tried the suggestions here:
>"https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/;
>to no avail.
>
>Last, but not least:
>
>sam@horus ~/fis-gtm-cygwin
>$ cmake --version
>cmake version 3.4.3
>
>CMake suite maintained and supported by Kitware (kitware.com/cmake).
>
>sam@horus ~/fis-gtm-cygwin
>$ uname -a
>CYGWIN_NT-10.0-WOW horus 2.2.0(0.289/5/3) 2015-08-03 12:49 i686 Cygwin

-- 

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, 

Re: [CMake] how to map configurations from include_external_msproject() ?

[Hendrik Sattler]

Hi,

Am 9. Februar 2016 13:36:03 MEZ, schrieb Gerhard Pobinger 
:
>I'm trying to include legacy Visual Studio projects into a cmake
>generated
>solution like this:
>
>project(Crypto)
>
>include_external_msproject(${PROJECT_NAME}_vcproj
>   "${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_NAME}_vs90.vcproj"
>)
>
># add_dependencies(${PROJECT_NAME}_vcproj
># )
>
>add_library(${PROJECT_NAME} INTERFACE)
>
>target_link_libraries(${PROJECT_NAME} INTERFACE
>   debug ${LIB_PATH_DEBUG}/${PROJECT_NAME}.lib 
>   optimized ${LIB_PATH_RELEASE}/${PROJECT_NAME}.lib
>)
>
>add_dependencies(${PROJECT_NAME}
>   ${PROJECT_NAME}_vcproj
>)
>
>This works only as long as the vcproj-files contain a configuration
>named
>'release' and 'debug', but when they don't it seems there is no way to
>map
>the existing configuration names (as also requested in
>https://cmake.org/pipermail/cmake/2010-April/036388.html). I tried the
>proposed way with imported targets, but I didn't succeed.
>
>How can I map a configuration of an external ms-project (e.g.
>'release_shared') into a configuration (e.g. 'release') of the
>cmake-generated solution? The problem is that simply adding a
>configuration
>named 'release' works, of course, but then I'd have to change the
>external
>vcproj...

...and additionally this might be impossible/very hard for e.g. qmake 
autogenerated vcprojx files.

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] PROPERTY for list of link libraries

[Hendrik Sattler]

Am 22. Januar 2016 15:23:53 MEZ, schrieb Tom Kacvinsky 
:
>I have need for a cross platform methods of getting libraries linked
>into an executable.
>
>Say for instance, we have
>
>add_library(foo STATIC a.c)
>add_exceutable(bar b.c)
>target_link_libraries(bar foo)
>
>So I know for that bar has a dependency on foo.lib (on Windows) and
>libfoo.a on Linux.
>
>And so forth.  What I would like to do is after everything is set up,
>query the properties of bar
>and find the list of libraries linked into bar in such a fashion I get
>that platform's specific library name (instead of the library's target
>name).

Is that the description of your problem or part of your idea of a solution?

If you need the real list after the executable is built, you can use
https://cmake.org/cmake/help/v3.4/module/GetPrerequisites.html

I use that to assemble a  build directory on windows where the executable can 
be debugged easily. Use it as part of a post build cmake script that of 
configured with the proper search paths.

>IS this possible?  I read the docs and didn't see a property for
>getting this list.  Did I miss something?  If so I plan on using
>either get_property of get_target_property.
>
>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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] add_custom_command scope

[Hendrik Sattler]

Am 19. Januar 2016 12:30:39 MEZ, schrieb Lars :
> Hello,
> 
>Using CMake 3.3 and VS2012.
> 
>The below cmake scripts generate "Policy CMP0040 is not set: The target
>in the TARGET signature of add_custom_command must exists". Why cannot
>the custom/CMakeLists.txt file see the target created in
>app/CMakeLists.txt ? Moving the ADD_CUSTOM_COMMAND to the
>app/CMakeLists.txt fixes the problem but I would like to keep them
>separate if possible.
> 
>PROJECT(TEST)
>ADD_DIRECTORY(app)
>ADD_DIRECTORY(custom)
> 
>The app CMakeLists.txt looks like this;
>ADD_EXECUTABLE(app main.cpp)
>TARGET_LINK_LIBRARIES(app)
> 
>The custom CMakeLists.txt looks like this;
>ADD_CUSTOM_COMMAND(
>  TARGET app 
>  POST_BUILD
>  COMMAND tbd.exe)
> 
>Appreciate any input.

Make that its own custom target and let it depend on app target.

>Kind regards, Lars
> 
>
>

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] providing host binary and target library cmake-package when cross compiling

[Hendrik Sattler]

You didn't answer my points b and c, only a.

Am 19. Oktober 2015 18:45:25 MESZ, schrieb Owen Alanzo Hogarth 
<gurenc...@gmail.com>:
>this is not an in source build.
>
>to do matrix vector multiplication matrix module needs to have access
>to
>the vector class.
>
>
>I'll add the source code for these modules here:
>http://pastebin.com/aj01ycRQ
>
>I think the structure should be a little clearer with all that I've
>provided.
>This is the previous link to the cmake folder structure and
>cmakelists.txt
>files: http://pastebin.com/BnVTnegP
>
>
>On Tue, Oct 20, 2015 at 12:33 AM, Hendrik Sattler
><p...@hendrik-sattler.de>
>wrote:
>
>>
>>
>> Am 19. Oktober 2015 17:33:55 MESZ, schrieb Owen Alanzo Hogarth <
>> gurenc...@gmail.com>:
>> >This is the entire project as it stands right now. I have tried
>> >changing
>> >from using relative to more absolute directory names in my project
>but
>> >I
>> >still get the same build errors.
>> >
>> >This pastebin has all the relevant code:
>http://pastebin.com/BnVTnegP
>>
>> a.
>> You user in-source build, don't do that.
>>
>> b.
>> You have the vector3 target defined in the matrix4 folder and vice
>versa?
>> Why?
>>
>> c.
>> Because of b. the targets are defined in wrong order. That's why he
>tries
>> to find a library that is not present.
>>
>> >Anyone can see anything wrong with this?
>> >
>> >On Mon, Oct 19, 2015 at 10:11 PM, Pascal Bach
><pascal.b...@siemens.com>
>> >wrote:
>> >
>> >> Hello
>> >>
>> >> I'm working on CMake support for Apache Thrift [1].
>> >> It is currently already buildable using CMake. However while
>trying
>> >to add
>> >> support for generating a ThriftConfig.cmake I ran into some issues
>> >> related to cross compilation.
>> >>
>> >> Thrift has the following components relevant to the problem:
>> >>
>> >> C++ library (.so library)
>> >> Thrift compiler (binary)
>> >>
>> >> End users/developers usually us thrift in the following way:
>> >> Thrift IDL ==[Thrift compiler]==> C++ files ==[GCC + Link with
>> >> thrift.so]==> final.so
>> >>
>> >> My idea for the resulting ThriftConfig.cmake was to provide two
>> >imported
>> >> targets Thrift::libthrift and Thrift::compiler.
>> >> Thrift::compiler can be used to generate C++ files from Thrift
>IDLs
>> >and
>> >> Thrift::libthrift is what the resulting binary should link
>against.
>> >> This works well if no cross compilation is involved.
>> >>
>> >>
>> >> Now for the cross compilation case. I'm using OpenEmbedded [2]
>which
>> >> provides two sysroot directories:
>> >> 1. sysroot_x86 containing binaries and libraries for the host:
>> >> libthrift.so (x86 library), thrift (x86 executable)
>> >> 2. sysroot_arm containing binaries and libraries for the target:
>> >> libthrift.so (arm library), thrift (arm executable)
>> >>
>> >> In the cross compiling case the Thrift::compiler target must be
>> >executable
>> >> on the HOST and Thrift::libthrift must be a target library.
>> >> This means the library should be from sysroot_arm but the binary
>from
>> >> sysroot_x86.
>> >> I'm not able express this an a good way.
>> >>
>> >> Does anyone know how to do this? Is there an example how this
>could
>> >be
>> >> done?
>> >>
>> >> Thanks for your help.
>> >>
>> >> Regards
>> >> Pascal
>> >>
>> >>
>> >> [1] http://thrift.apache.org/
>> >> [2] http://www.openembedded.org/wiki/Main_Page
>> >> --
>> >>
>> >> 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 Kit

Re: [CMake] providing host binary and target library cmake-package when cross compiling

[Hendrik Sattler]

Am 19. Oktober 2015 17:33:55 MESZ, schrieb Owen Alanzo Hogarth 
:
>This is the entire project as it stands right now. I have tried
>changing
>from using relative to more absolute directory names in my project but
>I
>still get the same build errors.
>
>This pastebin has all the relevant code: http://pastebin.com/BnVTnegP

a.
You user in-source build, don't do that.

b.
You have the vector3 target defined in the matrix4 folder and vice versa? Why?

c.
Because of b. the targets are defined in wrong order. That's why he tries to 
find a library that is not present.

>Anyone can see anything wrong with this?
>
>On Mon, Oct 19, 2015 at 10:11 PM, Pascal Bach 
>wrote:
>
>> Hello
>>
>> I'm working on CMake support for Apache Thrift [1].
>> It is currently already buildable using CMake. However while trying
>to add
>> support for generating a ThriftConfig.cmake I ran into some issues
>> related to cross compilation.
>>
>> Thrift has the following components relevant to the problem:
>>
>> C++ library (.so library)
>> Thrift compiler (binary)
>>
>> End users/developers usually us thrift in the following way:
>> Thrift IDL ==[Thrift compiler]==> C++ files ==[GCC + Link with
>> thrift.so]==> final.so
>>
>> My idea for the resulting ThriftConfig.cmake was to provide two
>imported
>> targets Thrift::libthrift and Thrift::compiler.
>> Thrift::compiler can be used to generate C++ files from Thrift IDLs
>and
>> Thrift::libthrift is what the resulting binary should link against.
>> This works well if no cross compilation is involved.
>>
>>
>> Now for the cross compilation case. I'm using OpenEmbedded [2] which
>> provides two sysroot directories:
>> 1. sysroot_x86 containing binaries and libraries for the host:
>> libthrift.so (x86 library), thrift (x86 executable)
>> 2. sysroot_arm containing binaries and libraries for the target:
>> libthrift.so (arm library), thrift (arm executable)
>>
>> In the cross compiling case the Thrift::compiler target must be
>executable
>> on the HOST and Thrift::libthrift must be a target library.
>> This means the library should be from sysroot_arm but the binary from
>> sysroot_x86.
>> I'm not able express this an a good way.
>>
>> Does anyone know how to do this? Is there an example how this could
>be
>> done?
>>
>> Thanks for your help.
>>
>> Regards
>> Pascal
>>
>>
>> [1] http://thrift.apache.org/
>> [2] http://www.openembedded.org/wiki/Main_Page
>> --
>>
>> 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:
>> http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] C++11 flag not being added

[Hendrik Sattler]

Am 16. Oktober 2015 11:29:48 MESZ, schrieb Petr Bena :
>I think you completely misunderstood me. I know I can install it on my
>machine, but I can hardly install it on PC's or servers of users who
>use my program.
>
>I want to make it as easy as possible to let users compile my program.
>Having to install anything by hand instead of system package manager
>is a big overhead to majority of users. CMake 3x is too new, it's
>available by default almost nowhere, meaning this option is not
>available to me at this time. Maybe in few years the situation will
>change, but for now I will resort to that hack which works on older
>versions that are generally available everywhere.

And what are those systems that bring an ancient cmake version but real C++11 
support? Note that many C++ libraries must be recompiled with c++11 enabled 
during compilation when you want to use them in your C++11 program.

>On Fri, Oct 16, 2015 at 11:26 AM, Pau Garcia i Quiles
> wrote:
>> Hello,
>>
>> CMake 3.3.1 is available from my PPA, in case it helps:
>>
>> https://launchpad.net/~pgquiles/+archive/ubuntu/ppa
>>
>>
>>
>> On Fri, Oct 16, 2015 at 10:58 AM, Petr Bena 
>wrote:
>>>
>>> If I did that nearly nobody would be able to compile my program as
>>> cmake >= 3.1 is extremely rare on most distributions. Even ubuntu's
>>> PPA builder has some ancient version.
>>>
>>> On Fri, Oct 16, 2015 at 9:44 AM, Petr Kmoch 
>wrote:
>>> > Hi Petr.
>>> >
>>> > You're using a feature (`CMAKE_CXX_STANDARD`) introduced in CMake
>>> > version
>>> > 3.1, so you should require a minimum version >= that.
>>> >
>>> > You can learn the version of CMake by running `cmake --version`
>>> >
>>> > Petr
>>> >
>>> > On Thu, Oct 15, 2015 at 5:45 PM, Petr Bena 
>wrote:
>>> >>
>>> >> What do you mean by "target" property? I don't see any target
>>> >> mentioned there. I don't have this line in there. I don't know
>which
>>> >> CMake this is, it failed on server we use for unit tests, but I
>have
>>> >> required min. version set to 2.8.7
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Oct 15, 2015 at 5:41 PM, Matthew S Wallace
>>> >>  wrote:
>>> >> > What version of CMake are you using?  I’m using 3.3.2.  The
>only
>>> >> > other
>>> >> > thing I did was:
>>> >> >
>>> >> > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED)
>>> >> >
>>> >> > I’m guessing this probably does nothing since it is probably a
>target
>>> >> > property.
>>> >> >
>>> >> > -Matt
>>> >> >
>>> >> >> On Oct 15, 2015, at 10:34 AM, Petr Bena 
>wrote:
>>> >> >>
>>> >> >> Can you elaborate on it a bit?
>>> >> >>
>>> >> >> I put set(CMAKE_CXX_STANDARD 11) as first line of my
>CMakeLists and
>>> >> >> it
>>> >> >> still doesn't work, without the hack I used I get errors while
>>> >> >> compiling.
>>> >> >>
>>> >> >> Can you give me example file in which it works? I guess there
>is
>>> >> >> more
>>> >> >> needed for it to work.
>>> >> >>
>>> >> >> On Tue, Oct 13, 2015 at 7:12 PM, Matthew S Wallace
>>> >> >>  wrote:
>>> >> >>> Thanks, setting the global variable solved my issue.
>>> >> >>>
>>> >> >>> -Matt
>>> >> >>>
>>> >>  On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl
>>> >>   wrote:
>>> >> 
>>> >>  Hi,
>>> >> 
>>> >>  CXX_STANDARD is a target property, not a global one. You can
>>> >>  either
>>> >>  set
>>> >>  CXX_STANDARD for every target that needs it, or set it
>globally by
>>> >>  changing
>>> >>  the default value.
>>> >> 
>>> >>  You can do the latter by setting the variable
>CMAKE_CXX_STANDARD
>>> >>  before
>>> >>  defining any target that depends on it:
>>> >> 
>>> >>  set(CMAKE_CXX_STANDARD 11)
>>> >> 
>>> >>  HTH,
>>> >>  Johannes
>>> >> 
>>> >>  On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote:
>>> >> > I have the following two lines in my CMakeLists.txt
>>> >> >
>>> >> > set_property(GLOBAL PROPERTY CXX_STANDARD 11)
>>> >> > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED)
>>> >> >
>>> >> > However when compiling some of my source files, the
>-std=c++11
>>> >> > flag
>>> >> > is not
>>> >> > added.
>>> >> >
>>> >> > Just for good measure I added:
>>> >> > target_compile_features(my_target PRIVATE cxx_strong_enums)
>to
>>> >> > the
>>> >> > target
>>> >> > that was having the problem.
>>> >> >
>>> >> > Not sure if it matters, but in this case the compile error
>I’m
>>> >> > getting is
>>> >> > complaining because I’m referencing a fully scoped enum. 
>If I
>>> >> > explicitly
>>> >> > include -std=c++11 in my compile flags, everything works.
>>> >> >
>>> >> > I’m thinking I’m probably just misunderstanding how
>CXX_STANDARD
>>> >> > works, but
>>> >> > any help would be appreciated.
>>> >> >

Re: [CMake] C++11 flag not being added

[Hendrik Sattler]

Am 16. Oktober 2015 11:29:48 MESZ, schrieb Petr Bena :
>I think you completely misunderstood me. I know I can install it on my
>machine, but I can hardly install it on PC's or servers of users who
>use my program.
>
>I want to make it as easy as possible to let users compile my program.
>Having to install anything by hand instead of system package manager
>is a big overhead to majority of users. CMake 3x is too new, it's


Hey, 3.0.2 is even available in Debian stable, and that really says something 
about older versions!


>available by default almost nowhere, meaning this option is not
>available to me at this time. Maybe in few years the situation will
>change, but for now I will resort to that hack which works on older
>versions that are generally available everywhere.
>
>On Fri, Oct 16, 2015 at 11:26 AM, Pau Garcia i Quiles
> wrote:
>> Hello,
>>
>> CMake 3.3.1 is available from my PPA, in case it helps:
>>
>> https://launchpad.net/~pgquiles/+archive/ubuntu/ppa
>>
>>
>>
>> On Fri, Oct 16, 2015 at 10:58 AM, Petr Bena 
>wrote:
>>>
>>> If I did that nearly nobody would be able to compile my program as
>>> cmake >= 3.1 is extremely rare on most distributions. Even ubuntu's
>>> PPA builder has some ancient version.
>>>
>>> On Fri, Oct 16, 2015 at 9:44 AM, Petr Kmoch 
>wrote:
>>> > Hi Petr.
>>> >
>>> > You're using a feature (`CMAKE_CXX_STANDARD`) introduced in CMake
>>> > version
>>> > 3.1, so you should require a minimum version >= that.
>>> >
>>> > You can learn the version of CMake by running `cmake --version`
>>> >
>>> > Petr
>>> >
>>> > On Thu, Oct 15, 2015 at 5:45 PM, Petr Bena 
>wrote:
>>> >>
>>> >> What do you mean by "target" property? I don't see any target
>>> >> mentioned there. I don't have this line in there. I don't know
>which
>>> >> CMake this is, it failed on server we use for unit tests, but I
>have
>>> >> required min. version set to 2.8.7
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Oct 15, 2015 at 5:41 PM, Matthew S Wallace
>>> >>  wrote:
>>> >> > What version of CMake are you using?  I’m using 3.3.2.  The
>only
>>> >> > other
>>> >> > thing I did was:
>>> >> >
>>> >> > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED)
>>> >> >
>>> >> > I’m guessing this probably does nothing since it is probably a
>target
>>> >> > property.
>>> >> >
>>> >> > -Matt
>>> >> >
>>> >> >> On Oct 15, 2015, at 10:34 AM, Petr Bena 
>wrote:
>>> >> >>
>>> >> >> Can you elaborate on it a bit?
>>> >> >>
>>> >> >> I put set(CMAKE_CXX_STANDARD 11) as first line of my
>CMakeLists and
>>> >> >> it
>>> >> >> still doesn't work, without the hack I used I get errors while
>>> >> >> compiling.
>>> >> >>
>>> >> >> Can you give me example file in which it works? I guess there
>is
>>> >> >> more
>>> >> >> needed for it to work.
>>> >> >>
>>> >> >> On Tue, Oct 13, 2015 at 7:12 PM, Matthew S Wallace
>>> >> >>  wrote:
>>> >> >>> Thanks, setting the global variable solved my issue.
>>> >> >>>
>>> >> >>> -Matt
>>> >> >>>
>>> >>  On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl
>>> >>   wrote:
>>> >> 
>>> >>  Hi,
>>> >> 
>>> >>  CXX_STANDARD is a target property, not a global one. You can
>>> >>  either
>>> >>  set
>>> >>  CXX_STANDARD for every target that needs it, or set it
>globally by
>>> >>  changing
>>> >>  the default value.
>>> >> 
>>> >>  You can do the latter by setting the variable
>CMAKE_CXX_STANDARD
>>> >>  before
>>> >>  defining any target that depends on it:
>>> >> 
>>> >>  set(CMAKE_CXX_STANDARD 11)
>>> >> 
>>> >>  HTH,
>>> >>  Johannes
>>> >> 
>>> >>  On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote:
>>> >> > I have the following two lines in my CMakeLists.txt
>>> >> >
>>> >> > set_property(GLOBAL PROPERTY CXX_STANDARD 11)
>>> >> > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED)
>>> >> >
>>> >> > However when compiling some of my source files, the
>-std=c++11
>>> >> > flag
>>> >> > is not
>>> >> > added.
>>> >> >
>>> >> > Just for good measure I added:
>>> >> > target_compile_features(my_target PRIVATE cxx_strong_enums)
>to
>>> >> > the
>>> >> > target
>>> >> > that was having the problem.
>>> >> >
>>> >> > Not sure if it matters, but in this case the compile error
>I’m
>>> >> > getting is
>>> >> > complaining because I’m referencing a fully scoped enum. 
>If I
>>> >> > explicitly
>>> >> > include -std=c++11 in my compile flags, everything works.
>>> >> >
>>> >> > I’m thinking I’m probably just misunderstanding how
>CXX_STANDARD
>>> >> > works, but
>>> >> > any help would be appreciated.
>>> >> >
>>> >> > -Matt
>>> >> 
>>> >>  --
>>> >> 
>>> >>  Powered by www.kitware.com
>>> >> 
>>> >> 

Re: [CMake] C++11 flag not being added

[Hendrik Sattler]

Am 16. Oktober 2015 13:38:27 MESZ, schrieb Petr Bena <benap...@gmail.com>:
>By stable you mean Jessie that was recently released and is almost
>nowhere in production yet? :)
>
>On my debian server:
>
>$ cmake --version
>cmake version 2.8.9
>
>On one of wikimedia's ubuntu servers (the newer ones):
>
>$ cmake --version
>cmake version 2.8.12.2
>
>On travis-ci cmake is about 2.8.7 and on ubuntu PPA builder it's
>probably same.
>
>And we aren't even talking about 3.0, but 3.1 or newer. One would need
>to be truly naive to expect newer version on some stable production
>systems, that usually run well established older software (eg.
>majority of them do).
>
>On my dev PC I have last CMake of course, but I need to be able to
>compile on other systems as well :)
>
>This code is meant to be cross-platform and buildable on most of
>supported OS'es, even on older versions. I sincerely hate programs
>that requires extremely latest versions of tools or libraries for them
>to work, because these are usually hard to build.

They want to self-compile the latest of your software but use several years old 
versions of everything else?
I'd understand the Ubuntu use case but not the Debian oldstable one. 

If everyone develops like this, the software system grinds to a halt. 
Recursively, I mean.

Just as a reminder for you regarding people of other systems: using C++11 
excludes a lot of older compilers, e.g. MS VS6 or 7.1 or 8 or 9 ;-)

OTOH, if you have a very specific target audience...

>On Fri, Oct 16, 2015 at 11:56 AM, Hendrik Sattler
><p...@hendrik-sattler.de> wrote:
>>
>>
>> Am 16. Oktober 2015 11:29:48 MESZ, schrieb Petr Bena
><benap...@gmail.com>:
>>>I think you completely misunderstood me. I know I can install it on
>my
>>>machine, but I can hardly install it on PC's or servers of users who
>>>use my program.
>>>
>>>I want to make it as easy as possible to let users compile my
>program.
>>>Having to install anything by hand instead of system package manager
>>>is a big overhead to majority of users. CMake 3x is too new, it's
>>
>>
>> Hey, 3.0.2 is even available in Debian stable, and that really says
>something about older versions!
>>
>>
>>>available by default almost nowhere, meaning this option is not
>>>available to me at this time. Maybe in few years the situation will
>>>change, but for now I will resort to that hack which works on older
>>>versions that are generally available everywhere.
>>>
>>>On Fri, Oct 16, 2015 at 11:26 AM, Pau Garcia i Quiles
>>><pgqui...@elpauer.org> wrote:
>>>> Hello,
>>>>
>>>> CMake 3.3.1 is available from my PPA, in case it helps:
>>>>
>>>> https://launchpad.net/~pgquiles/+archive/ubuntu/ppa
>>>>
>>>>
>>>>
>>>> On Fri, Oct 16, 2015 at 10:58 AM, Petr Bena <benap...@gmail.com>
>>>wrote:
>>>>>
>>>>> If I did that nearly nobody would be able to compile my program as
>>>>> cmake >= 3.1 is extremely rare on most distributions. Even
>ubuntu's
>>>>> PPA builder has some ancient version.
>>>>>
>>>>> On Fri, Oct 16, 2015 at 9:44 AM, Petr Kmoch <petr.km...@gmail.com>
>>>wrote:
>>>>> > Hi Petr.
>>>>> >
>>>>> > You're using a feature (`CMAKE_CXX_STANDARD`) introduced in
>CMake
>>>>> > version
>>>>> > 3.1, so you should require a minimum version >= that.
>>>>> >
>>>>> > You can learn the version of CMake by running `cmake --version`
>>>>> >
>>>>> > Petr
>>>>> >
>>>>> > On Thu, Oct 15, 2015 at 5:45 PM, Petr Bena <benap...@gmail.com>
>>>wrote:
>>>>> >>
>>>>> >> What do you mean by "target" property? I don't see any target
>>>>> >> mentioned there. I don't have this line in there. I don't know
>>>which
>>>>> >> CMake this is, it failed on server we use for unit tests, but I
>>>have
>>>>> >> required min. version set to 2.8.7
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Thu, Oct 15, 2015 at 5:41 PM, Matthew S Wallace
>>>>> >> <mwall...@ccmtrading.com> wrote:
>>>>> >> > What version of CMake are you using?  I’m using 3.3.2.  The
>>>only
>>>>> >> &

Re: [CMake] How to create a custom solution with Visual Studio 2010 generator?

[Hendrik Sattler]

Hi,


Am 22. September 2015 08:49:57 MESZ, schrieb "Golebiewski, Jakub" 
:
>I have about 620 targets (VS projects) so when I open Main Project.sln
>(with 620 projects) in VS it is impossible to work with.
>Currently cmake produces .sln for each Sub Project but includes
>dependencies from other projects and that's something I don’t want
>Since the amount of projects in each .sln increases the further I go
>and most of them (later in the dependency chain) are not possible to
>work
>with either. I'm trying to divide it into .slns that developers could
>work with in VS.

That is exactly what imported targets are for. However, they refer to already 
built projects. I'd also suggest a two-step approach: first configure and build 
the thing with all projects in the solution. The libraries need to create cmake 
build tree export config files. After that step, define a cmake variable to 
switch to using the previously created export config files only. These create 
the imported targets and don't show up in the IDE.

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Need help with COMPILE_DEFINITIONS_

[Hendrik Sattler]

Am 14. September 2015 22:25:00 MESZ, schrieb Pau Garcia i Quiles 
:
>Hello,
>
>Have you tried
>
>set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG
>-DATEST)

That would be the right thing for add_definitions() but not here.
He could try with generator expressions though.

>
>On Mon, Sep 14, 2015 at 9:35 PM, Carl Poirier
>
>wrote:
>
>> Hi folks,
>>
>> I need some help setting the COMPILE_DEFINITIONS_. I'm using
>the
>> Visual Studio 2008 generator. I use this command to do so which I
>took in
>> the notes  when the
>feature
>> was added:
>>
>> set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG
>ATEST)
>>
>> Then, once the solution and project is generated, I go into the
>project
>> properties under the C++ preprocessor and I can't see the define.
>Removing
>> the configuration name does set it correctly for all of them, so it
>leads
>> me to believe the rest of my CMakeLists.txt is fine:
>>
>> set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS ATEST)
>>
>> So is this supposed to work?
>>
>> Thank you,
>>
>> Carl
>>
>> --
>>
>> 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:
>> http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] linking: absolute path vs -l

[Hendrik Sattler]

Hi,

is the netcdf find module defining an imported target? AFAIK, imported targets 
are always linked by full path. Else the rules already mentioned apply.

HS


Am 28. August 2015 10:23:47 MESZ, schrieb "Nico Schlömer" 
:
>Hi everyone,
>
>I'm curious about when CMake decides to link a library by its absolute
>path
>and when it links using the `-l*` syntax. I came across this for the
>very
>simple test problem
>```
>cmake_minimum_required(VERSION 3.0)
>
>project(mytest)
>
>find_package(ZLIB REQUIRED)
>find_package(netCDF REQUIRED)
>
>add_executable(mytest main.cpp)
>target_link_libraries(
>  mytest
>  ${ZLIB_LIBRARIES}
>  ${netCDF_LIBRARIES}
>  )
>```
>The resulting link line is
>```
>/usr/bin/c++   CMakeFiles/mytest.dir/main.cpp.o  -o mytest
>-rdynamic
>-lz /usr/lib/x86_64-linux-gnu/libnetcdf.so.7.3.0
>```
>so ZLIB is linked with `-lz`, netCDF with the full absolute path.
>
>Seems inconsistent? (ZLIB by the way is found through CMake's
>FindZLIB.cmake, netCDF by their own export files.)
>
>So far, I had been under the impression that `-l*` defeats the purpose
>of
>CMake a little bit as it asks the linker to search in the system's
>paths
>for a libz.so, something CMake has already done.
>
>A little clarification here would be great.
>
>Cheers,
>Nico
>
>
>
>
>-- 
>
>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:
>http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to link the output of a custom command (VS2013) when the output is an obj file, since LinkObjects is hardcoded to false?

[Hendrik Sattler]

Hi,

why don't you just add the asm file to your add_library() call and enable the 
ASM language?

HS


Am 2. September 2015 09:21:11 MESZ, schrieb Nick Georghiou 
:
>Hi,
>
> 
>
>I have the custom command provided below which successfully creates
>mydll.obj in the correct intermediate directory. However the
>LinkObjects
>property of the custom command within Visual Studio 2013 is set to
>false and
>therefore the object file is not linked. Upon inspection of the CMake
>code,
>it seems that the LinkObjects property is hardcoded to false and there
>is no
>cmake option to specify otherwise.
>
> 
>
>Is there another way to get the object file to link that I am missing.
>Any
>help on this would be greatly appreciated.
>
> 
>
>---
>
> 
>
>My custom command:
>
> 
>
>add_custom_command(
>
>OUTPUT "$(IntDir)mydll.obj" 
>
> COMMAND ml64.exe /c /nologo /Fo"$(IntDir)mydll.obj" /Zi "%(FullPath)" 
>
>MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/mydll.asm)
>
> 
>
>---
>
> 
>
>CMake code in file cmVisualStudio10TargetGenerator.cxx:
>
> 
>
>if(this->LocalGenerator->GetVersion()
>
>>
>cmGlobalVisualStudioGenerator::VS10)
>
>  {
>
>  // VS >= 11 let us turn off linking of custom command outputs.
>
>  this->WritePlatformConfigTag("LinkObjects", i->c_str(), 3);
>
>  (*this->BuildFileStream ) << "false\n";
>
>  }
>
>}
>
> 
>
> 
>
>
>
>
>
>-- 
>
>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:
>http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Visual Studio - Ninja Generator

[Hendrik Sattler]

Hi,

did you really enable parallel compiling in VS with /MP24 or the like? Note 
that using devenv to build uses the number from the IDE user settings but using 
msbuild needs a command line option.

Else just create a custom target that calls cmake for ninja and afterwards 
ninja itself in yet another build tree. you can limit the creation of that 
target to if(MSVC_IDE).

HS


Am 31. August 2015 16:35:01 MESZ, schrieb Guillaume Dumont 
:
>Hi all,
>
>I would like to know what kind of effort would it take to generate a
>Visual
>Studio generator that bypasses the normal MSBuild build and uses Ninja
>instead. I have been working on different projects which build much
>faster
>with ninja than MSBuild (several orders of magnitude on a machine with
>24
>cores). Still I like to use the Visual Studio environment to use the
>debugger. Using ninja is especially useful for projects with a lot of
>CUDA
>files which are built sequentially for every target using MSVS.
>
>I would like to contribute but I don't really know where to start and
>if
>such an effort already exists.
>
>-- 
>Guillaume Dumont
>=
>dumont.guilla...@gmail.com
>
>
>
>
>-- 
>
>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:
>http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] warn if features used that require cmake-x.y

[Hendrik Sattler]

Am 3. Juli 2015 20:23:26 MESZ, schrieb Alexander Neundorf 
a.neundorf-w...@gmx.net:
On Thursday, July 02, 2015 04:13:40 Stuermer, Michael  SP/HZA-ZSEP
wrote:
 Have a look at cmake_minimum_required() and cmake_policy(). I think
with
 these both it should be possible to verify you are using a cmake
version
 that provides all features which are required by your project.

no, what he is talking about is the other way round.
He wants to make sure nobody accidentially introduces cmake code which 
requires a newer version of cmake than what cmake_minimum_required()
states.

I think that's really hard to implement, but it would be nice to have.

This would also involve all variables and properties and all find modules.

I'd say that the only way to make sure that it works with that version is to 
actually test it...

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Installing systemd service files that point to my installed location

[Hendrik Sattler]

Am 12. Juni 2015 16:46:47 MESZ, schrieb Matthew Karas mkarasc...@gmail.com:
This is probably and XY problem but...

I'm trying to install a systemd file in my cmake.

The service file needs to point at the installed destination of my
build after I make install.

I was trying to use  CONFIGURE_FILE

When I tried to do this - the variable is blank because the configure
file occurs during the cmake setup part - not the make install
DESTDIR=~/blah part.

Is there any way to configure files while I'm installing them, or to
configure a file as part of a post install script?

You should  not base generated file content on DESTDIR as this should be used 
e.g. for packaging to an intermediate directory. Use only CMAKE_INSTALL_PREFIX. 
You can use configure_file() for this.

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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] cmake automoc fails when enabling autorcc

[Hendrik Sattler]

Hi,

can someone explain to me what goes wrong?

I am using Visual Studio 2010. CMake is 3.2.2 but also I tried 3.3-rc1.

I created a small example that shows the problem. I created it from
scratch and it instantly fails for me.
You need to create a foo.png to get the qrc to actually create the
source file (actually 2nd bug that CMake doesn't warn here).

First run, comment out the onTst2 slot function (both h and cpp file),
it should build.
Then comment it before 2nd run.
I get:
error C3861: 'onTst2': identifier not found (moc_main.cpp)

This file is auto-generated and thus was not updated. - Should not
happen.
I also tried to manually run cmake, it won't help.

However, commenting mainx.qrc helps! Or using qt4_add_resources() and
disabling CMAKE_AUTORCC!
Suddenly, the bugtest_automoc target is gone in VS and it compiles
again, even after adding/removing Qt slot functions.
BTW, why is this target called bugtest_automoc and not bugtest_autogen?

The whole thing looks strange as bugtest target still has a
qrc_mainx.cpp.rule but bugtest_automoc also has such a rule.
The bugtest.automoc.rule file properties show no real command:
-
setlocal
cd D:\bugtest\cmake-autogen\build
if %errorlevel% neq 0 goto :cmEnd
D:
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal  call :cmErrorLevel %errorlevel%  goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
-
Is that supposed to actually do something?

Can someone point me to a possible solution?
I'm back to qt4_add_resources() for now.

Regards,

HS


CMakeLists.txt:
--
cmake_minimum_required ( VERSION 3.0.2 )
cmake_policy ( VERSION 3.0.2 )

project ( bugtest CXX )

find_package ( Qt4 )

set ( CMAKE_INCLUDE_CURRENT_DIR ON )
set ( CMAKE_AUTOMOC ON )
set ( CMAKE_AUTORCC ON )

add_executable ( bugtest
  main.cpp
  mainx.qrc
)
target_link_libraries ( bugtest Qt4::QtCore )
--

main.h:
--
#include QObject

class tst1 : public QObject
{
  Q_OBJECT

 public slots:
   void onTst1();
   //void onTst2();
};
--

main.cpp:
--
#include main.h

void tst1::onTst1()
{
}

// void tst1::onTst2()
// {
// }

int main( int argc, char **argv)
{
  return 0;
}
--

mainx.qrc:
--
!DOCTYPE RCCRCC version=1.0
qresource
  filefoo.png/file
/qresource
/RCC
--

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] install/strip target doesn't exist?

[Hendrik Sattler]

Am 11. Mai 2015 18:46:13 MESZ, schrieb J Decker d3c...@gmail.com:
command:
  cmake.exe --build . --config release --target install/strip --
output:
  mingw32-make.exe: *** No rule to make target 'install\strip'.  Stop.

It reverses the slash?
install doesn't always strip?
does package strip?

Is there actually anything to strip from a windows executable?

Even on Linux: stripping a binary without debug symbols?

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Chicken and egg problem with cmake_minimum_required(...), project(...), and CMAKE_SYSTEM_NAME

[Hendrik Sattler]

Am 1. Mai 2015 12:41:50 MESZ, schrieb David Cole via CMake cmake@cmake.org:
I would strongly recommend NOT having different minimum versions for
Linux vs. everywhere else.

I did something similar one but based on the generator.
It might makes sense when you generally want to support an older version but 
some cases are broken. For me it was AUTO_DEPENDS. However a new version might 
be problematic in combination with other things.

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Adding files to project that don't exist

[Hendrik Sattler]

Am 30. April 2015 14:04:08 MESZ, schrieb coo...@megaroms.co.uk:
Hi,

I'm using Doxygen to generate my project documentation and have a
custom
target to do it. Like this:

find_package( Doxygen )

if( DOXYGEN_FOUND )
configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/Doxyfile.in
${CMAKE_CURRENT_BINARY_DIR}/Doxyfile @ONLY )

add_custom_target( doc
   ${DOXYGEN_EXECUTABLE}
${CMAKE_CURRENT_BINARY_DIR}/Doxyfile
   WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
COMMENT Generating API documentation with Doxygen
VERBATIM
   SOURCES Doxyfile.in
)
endif( DOXYGEN_FOUND )

which works fine. However, I'd like to extend this so the generated
index.html file is shown as part of the doc project when I use the
Visual Studio generator. Is there a way to do this? If the file already
exist I can coax CMake to include the file by adding it to SOURCES but
when the file doesn't exist (most of the time) CMake gives an error.

Maybe the following works:
Make your doc custom target depend on the output file  index.html and run 
doxygen in that custom command.

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Install( Targets ) loses executable permission

[Hendrik Sattler]

Am 22. April 2015 04:01:40 MESZ, schrieb J Decker d3c...@gmail.com:
the library is built 'tasks.isp' with rwxr-xr-x
but it's installed with rw-r--r--

(platform is rasberry pi)

Normal libraries on linux don't need any executable bit set. That the linker 
creates files with that permission has probably other reasons.

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Supress generation of a Makefile

[Hendrik Sattler]

Am 18. März 2015 23:59:10 MEZ, schrieb aditya siram aditya.si...@gmail.com:
Hi all,
I have a cross platform project where Linux/Mac users will use the
standard
autoheader;autoconf;./configure .. routine, but on Windows users will
do
cmake .; make.

that's the wrong command

I am using CMake solely to substitute some variables in some
subdirectory
Makefile.in's.

Strange idea, really.

The problem is that there is an existing Makefile in the root of the
project that must not be disturbed but keeps getting overwritten
whenever I
run cmake ..

How do I stop CMake from generating a Makefile?

1. Don't have any file named CMakeLists.txt in that directory, give it some 
other name ending usually with .cmake
2. Use cmake -P

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Unreliable Find*.conf

[Hendrik Sattler]

Am 18. März 2015 07:23:12 MEZ, schrieb Damian Philipp damian.phil...@gmx.net:
Hello cmake-experts,

I am working on a project that uses a third-party library delivered in
binary form (TeamSpeak 3 SDK). My project is supposed to build on Win,
Linux, and OSX, so I decided to use cmake as a build tool. I have
started work on a Findts3sdk.cmake (find_package() in module mode) to
let cmake detect the library in the CMAKE_PREFIX_PATH on any of my
machines - file attached at the end of this mail.

My (current) problem is that a call to find_path() in my
Findts3sdk.cmake will not pick up the bin directory containing the
libraries, while another call did work to find the include directory.

WORKS (ts3sdk_INCLUDE_DIR == /path/to/ts3_sdk_3.0.3/include):
 find_path(ts3sdk_INCLUDE_DIR NAMES clientlib.h HINTS
${CMAKE_PREFIX_PATH}/include)

BROKEN (ts3sdk_LIBRARY_DIR == ts3sdk_LIBRARY_DIR-NOTFOUND):
 find_path(ts3sdk_LIBRARY_DIR NAMES libts3client_mac.dylib HINTS
${CMAKE_PREFIX_PATH}/bin)


CMAKE_PREFIX_PATH is possibly a list so the above does not always work.
IIRC Just use
 PATH_SUFFIXES bin
instead.
And use find_ library() instead.

I deduce from this that CMAKE_PREFIX_PATH is set correctly. I have
tried
the broken command with other names of the library file as well
(ts3client_mac, libts3client_mac, libts3client_mac.dylib,
ts3client_mac.dylib).

What do I have to fix to make find_path() pick up the library file?

I am currently on a Mac, using cmake 3.1.3 installed from MacPorts.
cmake is called with -DCMAKE_PREFIX_PATH=/path/to/ts3_sdk_3.0.3.
The layout of the library delivery is as follows:

 ts3_sdk_3.0.3
 ├── bin
 │   ├── libts3client_linux_amd64.so
 │   ├── libts3client_linux_x86.so
 │   ├── libts3client_mac.dylib
 │   ├── libts3server_freebsd_amd64.so
 │   ├── libts3server_freebsd_x86.so
 │   ├── libts3server_linux_amd64.so
 │   ├── libts3server_linux_x86.so
 │   ├── libts3server_mac.dylib
 │   ├── soundbackends
 │   ├── ts3client_win32.dll
 │   ├── ts3client_win64.dll
 │   ├── ts3server_win32.dll
 │   └── ts3server_win64.dll

Maybe you should start telling the makers of the SDK to fix their directory 
layout as .so and .dylib files do not belong to the bin folder but to the 
library folder. That would also make find_library() work more easily.
And naming the library differently for every case is just...strange.

 ├── include
 │   ├── clientlib.h
 │   ├── clientlib_publicdefinitions.h
 │   ├── public_definitions.h
 │   ├── public_errors.h
 │   ├── serverlib.h
 │   └── serverlib_publicdefinitions.h
 └── lib
 ├── ts3client_win32.lib
 ├── ts3client_win64.lib
 ├── ts3server_win32.lib
 └── ts3server_win64.lib

My current Findts3sdk.conf looks as follows:

 # Find the INCLULDE and LIBRARY path
 find_path(ts3sdk_INCLUDE_DIR NAMES clientlib.h HINTS
${CMAKE_PREFIX_PATH}/include)
 
 if (WIN32)
  set(ts3sdk_client_LIBRARIES ts3client_win32 ts3client_amd64)
  set(ts3sdk_server_LIBRARIES ts3server_win32 ts3server_amd64)
 elseif (APPLE)
  set(ts3sdk_client_LIBRARIES ts3client_mac)
  set(ts3sdk_server_LIBRARIES ts3server_mac)
 elseif (UNIX)
  set(ts3sdk_client_LIBRARIES ts3client_linux_x86
ts3client_linux_amd64)
  set(ts3sdk_server_LIBRARIES ts3server_linux_x86
ts3server_linux_amd64)
 endif()
 
 #find_path(ts3sdk_LIBRARY_DIR NAMES ${ts3sdk_client_LIBRARIES} HINTS
${CMAKE_PREFIX_PATH}/bin)
 find_path(ts3sdk_LIBRARY_DIR NAMES ts3client_mac.dylib HINTS
${CMAKE_PREFIX_PATH}/bin)
 #find_path(ts3sdk_LIBRARY_DIR NAMES ${ts3sdk_client_LIBRARIES}
${ts3sdk_server_LIBRARIES} HINTS ${CMAKE_PREFIX_PATH}/bin)

 # Combine into output information
 set(ts3sdk_INCLUDE_DIRS ${ts3sdk_INCLUDE_DIR})
 set(ts3sdk_LIBRARY_DIRS ${ts3sdk_LIBRARY_DIR})
 
 message(STATUS ts3sdk headers found in  ${ts3sdk_INCLUDE_DIRS})
 message(STATUS ts3sdk libraries used:  ${ts3sdk_client_LIBRARIES})
 message(STATUS ts3sdk libraries found in  ${ts3sdk_LIBRARY_DIR})

Regards,
Damian Philipp
-- 

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:
http://public.kitware.com/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

Re: [CMake] DEB package generated with cpack does not pass lintian check on Ubuntu

[Hendrik Sattler]

Hi,

you have to differ here:
lintian is for checking packaging policy of distribution packages for Debian 
and derivatives like Ubuntu.
Cpack does not necessarily create packages according to these policies but 
still valid packages. If dpkg eats it without errors, it's ok for 
out-of-distribution packages.

HS


Am 17. März 2015 00:25:18 MEZ, schrieb Bogdan Cristea crist...@gmail.com:
Hi

I have generated a DEB package with cpack, but the analysis with
lintian in Ubuntu reveals still some errors:

E: at: changelog-file-missing-in-native-package
E: at: control-file-has-bad-owner md5sums b/users != root/root
E: at: no-copyright-file
E: at: extended-description-is-empty
E: at: maintainer-name-missing a...@gmail.com
Use of uninitialized value $name in pattern match (m//) at
/usr/share/perl5/Lintian/Check.pm line 203.
E: at: wrong-file-owner-uid-or-gid usr/ 1000/100
E: at: wrong-file-owner-uid-or-gid usr/bin/ 1000/100
E: at: wrong-file-owner-uid-or-gid usr/bin/AT 1000/100
W: at: binary-without-manpage usr/bin/AT

Could someone tell me how can I solve these ?

thanks
Bogdan





-- 

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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Linking to Qt static libraries fails using cmake but not qmake (both OSX and Linux)

[Hendrik Sattler]

Hi,

that's because qmake uses its some extra files to track the additional 
libraries that are needed when you link qt statically (.prl IIRC).
You are missing these, somehow. Maybe the cmake files from qt5 don't handle 
this case?

HS


Am 10. März 2015 18:28:18 MEZ, schrieb paul johnson p77john...@gmail.com:
This has been driving me crazy for a while now. Occurs for both OSX and
Linux.

OSX Mavericks 10.9.5, openSUSE Linux 12.3
CMake 3.1.1
Qt 5.4.1 (both shared and static builds, compiled from source)

Using cmake to compile and link the simple Qt HelloWorld app against Qt
shared libraries works just fine.

Using the same cmake file and specifying the Qt static libraries
instead,
it fails in the linking (OSX: Undefined symbols for architecture
x86_64,
ld: symbol(s) not found for architecture x86_64’; LINUX: undefined
reference to …, collect2 error: ld returned 1 exit status)

Message would seem to point towards static libraries not compiled 64
bit.

But, if I use qmake to generate the makefile to use with the Qt static
libraries, it compiles and links with no problem. No symbol problem
here.
Seems to indicate the static libraries are fine.

Since using qmake seems to work fine I can’t pin down what the problem
is
with cmake.

Can anyone shed some light on this?

Source, CMakeLists.txt, and qmake .pro contents below. I’ve also
attached
failed linking output from OSX and linux cmake/make.

main.cpp:

#include QApplication
#include QPushButton

int main(int argc, char **argv)
{
QApplication app (argc, argv);

QPushButton button (Hello world !);
button.show();

return app.exec();
}


CMakeLists.txt:

cmake_minimum_required(VERSION 2.8.11)

project(helloworld)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
set(CMAKE_AUTOMOC ON)
find_package(Qt5Widgets REQUIRED)
add_executable(helloworld main.cpp)
target_link_libraries(helloworld Qt5::Widgets)


main.pro:

SOURCES = main.cpp
CONFIG += qt warn_on release
QT += core widgets gui


Thanks in advance.


Paul




-- 

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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Inconsistency with INSTALL(TARGETS) destinations...

[Hendrik Sattler]

Am 10. März 2015 23:33:41 MEZ, schrieb J Decker d3c...@gmail.com:
I recently added cmakelists to a library that didn't support cmake.
It started with a simple make system, and was easy to create and use
simple
cmake support.

I was building using visual studio, and this was my install command
   install( TARGETS MatrixSSL
LIBRARY DESTINATION bin
ARCHIVE DESTINATION lib )

that put the .DLL in bin and .lib in lib.

Then I had to change to using watcom to build, and the .DLL went
nowhere...
so I modified the line to...

   install( TARGETS MatrixSSL
RUNTIME DESTINATION bin
LIBRARY DESTINATION bin
ARCHIVE DESTINATION lib )

... then the DLL was installed into bin.

A bug, then. Dll files should always be installed to the RUNTIME destination.

I'm not sure which way is intended... or maybe it's something in each
of
the build environments that requires it to be different?


and just commentary...
Installing libraries is kind of a pain... (and this is probably
incomplete)


if( WIN32 )
 install( TARGETS MatrixSSL RUNTIME DESTINATION bin LIBRARY DESTINATION
bin ARCHIVE DESTINATION lib )
else( WIN32 )
   if( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
  install( TARGETS MatrixSSL DESTINATION lib64 )
   else( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
  install( TARGETS MatrixSSL DESTINATION lib )
   endif( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
endif( WIN32 )

And it's mostly wrong, e.g. lib64 is not correct for many systems. If you want 
Unix like subdirectories, use the GnuIntallDirs module. 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Fwd: [Bug 1199360] New: Parallel build of webkitgtk4 fails with cmake 3.2

[Hendrik Sattler]

Hi,

I'd assume that the problem is the perl script. It doesn't work correctly when 
run in parallel multiple times. This can happen when not all outputs are 
written before another make instance checks this rule.
So the first run creates the .perf file which is already empty by another 
instance when the first instance wants to use it.

HS


Am 6. März 2015 04:40:02 MEZ, schrieb Orion Poplawski or...@cora.nwra.com:
If any cmakers out there could help take a look at this, I'd very much 
appreciate it.

- Orion


 Forwarded Message 
Subject: [Bug 1199360] New: Parallel build of webkitgtk4 fails with 
cmake 3.2
Date: Fri, 06 Mar 2015 03:29:34 +
From: bugzi...@redhat.com
To: or...@cora.nwra.com

https://bugzilla.redhat.com/show_bug.cgi?id=1199360

 Bug ID: 1199360
Summary: Parallel build of webkitgtk4 fails with cmake 3.2
Product: Fedora
Version: 22
  Component: cmake
   Severity: medium
   Assignee: or...@cora.nwra.com
   Reporter: mcatanz...@gnome.org
 QA Contact: extras...@fedoraproject.org
  CC: he...@kde.org, jrez...@redhat.com, lti...@redhat.com,
 or...@cora.nwra.com, pmach...@redhat.com,
 rdie...@math.unl.edu



Description of problem: Parallel build of webkitgtk4 fails with cmake
3.2. I
wonder if it's a WebKit bug or a CMake bug.


Version-Release number of selected component (if applicable):
cmake-3.2.0-0.1.rc1.fc22


How reproducible: ...eh... always?


Steps to Reproduce:
1. Revert the latest commit to webkitgtk4 which disables parallel build
2. fedpkg build webkitgtk4


Actual results:
https://kojipkgs.fedoraproject.org//work/tasks/2915/9132915/build.log

The interesting part is this:

[ 15%] cd
/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore
 /usr/bin/perl
-I/builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/bindings/scripts
/builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/css/makeprop.pl 
--defines
 ENABLE_3D_RENDERING ENABLE_ACCELERATED_2D_CANVAS ENABLE_ACCESSIBILITY
ENABLE_CHANNEL_MESSAGING ENABLE_CONTEXT_MENUS 
ENABLE_CSS_BOX_DECORATION_BREAK
ENABLE_CSS_IMAGE_SET ENABLE_CSS_REGIONS ENABLE_CSS_SELECTORS_LEVEL4
ENABLE_DETAILS_ELEMENT ENABLE_DRAG_SUPPORT ENABLE_FULLSCREEN_API
ENABLE_GEOLOCATION ENABLE_ICONDATABASE ENABLE_INPUT_TYPE_COLOR
ENABLE_JIT
ENABLE_LEGACY_VENDOR_PREFIXES ENABLE_MATHML
ENABLE_MEDIA_CONTROLS_SCRIPT
ENABLE_MEMORY_SAMPLER ENABLE_METER_ELEMENT ENABLE_MHTML
ENABLE_NAVIGATOR_HWCONCURRENCY ENABLE_NETSCAPE_PLUGIN_API
ENABLE_NETWORK_PROCESS ENABLE_NOTIFICATIONS ENABLE_PICTURE_SIZES
ENABLE_PROMISES ENABLE_REQUEST_ANIMATION_FRAME
ENABLE_SATURATED_LAYOUT_ARITHMETIC ENABLE_SPELLCHECK ENABLE_STREAMS_API
ENABLE_SVG_FONTS ENABLE_TEMPLATE_ELEMENT ENABLE_TOUCH_EVENTS
ENABLE_USERSELECT_ALL ENABLE_USER_MESSAGE_HANDLERS ENABLE_VIDEO
ENABLE_VIDEO_TRACK ENABLE_VIEW_MODE_CSS_MEDIA ENABLE_WEB_AUDIO
ENABLE_WEB_SOCKETS ENABLE_WEB_TIMING ENABLE_WEBGL ENABLE_XHR_TIMEOUT
ENABLE_XSLT ENABLE_PLUGIN_PROCESS_GTK2 --preprocessor /usr/bin/c++ -E

-P -x
c++
/usr/bin/cmake -E cmake_progress_report
/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles
/usr/bin/cmake -E cmake_progress_report
/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles
/usr/bin/cmake -E cmake_progress_report
/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles
/usr/bin/cmake -E cmake_progress_report
/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles
/usr/bin/cmake -E cmake_progress_report
/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles
/usr/bin/cmake -E cmake_progress_report
/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles
[ 15%] [ 15%] [ 15%] [ 15%] [ 15%] Generating
../../DerivedSources/WebCore/SelectorPseudoElementTypeMap.gperf,
../../DerivedSources/WebCore/SelectorPseudoElementTypeMap.cpp
[ 15%] CSSPropertyNames.gperf: The input file is empty!
calling gperf failed: 256 at
/builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/css/makeprop.pl
line
1032.
Source/WebCore/CMakeFiles/WebCore.dir/build.make:155: recipe for target
'DerivedSources/WebCore/CSSPropertyNames.h' failed
make[2]: *** [DerivedSources/WebCore/CSSPropertyNames.h] Error 25
make[2]: *** Waiting for unfinished jobs...

Line 1032 of makeprop.pl:

system(\$gperf\ --key-positions=\*\ -D -n -s 2
CSSPropertyNames.gperf
--output-file=CSSPropertyNames.cpp) == 0 || die calling gperf failed:
$?;

So I guess CSSPropertyNames.gperf has not been built yet. Oh, but that 
file is
built by makeprop.pl, beginning with line 113:

open GPERF, CSSPropertyNames.gperf || die Could not open
CSSPropertyNames.gperf for writing;

So it doesn't SEEM like a CMake dependency issue... but the script is a

mess to
read, and I can imagine it not working if CSSPropertyNames.in was not 
properly
generated.

Now, in WebKit/Source/WebCore/CMakeLists.txt we have this:

# 

Re: [CMake] Setting environment variables on windows on install

[Hendrik Sattler]

Hi,

setting global environment variables in windows is just adding/editing some 
registry keys. As an alternative, you can run setx command in a cmd.exe 
instance.

HS


Am 24. Januar 2015 21:29:20 MEZ, schrieb Gonzalo Garramuno ggarr...@gmail.com:
I would like to set an environment variable in the NSIS installer,
other 
than PATH during the install.  Can someone show me how?

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12

[Hendrik Sattler]

Hi,

This makes cmake --build much less predictable across cmake versions and cmake 
projects.
How can I find out if msbuild is chosen without inspecting the cmake project?
Specifying this manually is not really an option... too complicated.

Or like that:
- run CMake
- get the CMAKE_VS_MSBUILD... from cache and at set 
CMAKE_MAKE_PROGRAM from it.

@Paul: You can probably modify the CMAKE_VS_MSBUILD... variable to add /m. But 
to compile in parallel should be s decision of the user, not the project, and 
thus a decision of the caller of cmake --build.

HS


Am 21. Januar 2015 15:05:32 MEZ, schrieb Brad King brad.k...@kitware.com:
On 01/20/2015 03:40 PM, Paul Smith wrote:
 Where can I go to find out more about how cmake --build chooses
whether
 to use msbuild vs. devenv?

The behavior was updated in 3.0 and is now described here:

 http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_MAKE_PROGRAM.html

In 2.8.12 and below we always stored CMAKE_MAKE_PROGRAM in
CMakeCache.txt
instead of waiting until build time to choose it.  This was problematic
because it was initialized before configuring the project so we could
not
know whether devenv had to be chosen for Intel Fortran support or not,
so it always chose devenv if available.  However, devenv does not work
when using an alternative PlatformToolset with CMAKE_GENERATOR_TOOLSET:

http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/46795/focus=46969

Therefore we had to switch to build-time selection of the build tool.
The change was mentioned in the 3.0 release notes:

 http://www.cmake.org/cmake/help/v3.0/release/3.0.0.html#other-changes
 Selection of the proper msbuild or devenv tool is now performed as
  late as possible when the solution (.sln) file is available so it
  can depend on project content.

On 01/21/2015 05:53 AM, Yves Frederix wrote:
 options like  'cmake --build . --config Release -- /m'. I checked and
 this indeed works as expected.

Yes.

 The above explains all my initial observations. However, the fix is
 not very handy. As I understood, one does not know until build time
 what exact build (devenv or msbuild) will be used by CMake

MSBuild will be used for VS = 10 unless Fortran code is involved.  You
can also add -DCMAKE_MAKE_PROGRAM=/path/to/msbuild.exe to explicitly
specify it.  Once that is in CMakeCache.txt then it will always be used
by cmake --build.

-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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12

[Hendrik Sattler]

Hi,

but msbuild does not use this setting from VS, only devenv does.

See option /m

HS


Am 20. Januar 2015 14:54:26 MEZ, schrieb David Cole via CMake cmake@cmake.org:
If you open the Tools  Options dialog in Visual Studio, and
navigate to the Projects and Solutions  Build and Run tab, what is
your maximum number of parallel project builds value?

For maximum parallel build capability, it should be set to the same as
the number of cores you have.


D


On Tue, Jan 20, 2015 at 7:10 AM, Yves Frederix
yves.frederix+cm...@gmail.com wrote:
 3.1.0:10m50s
 2.8.12:   4m02s
 3.1.0 (/MP): 6m29s
 2.8.12 (/MP): 3m48s

 I cannot reproduce that.  On my machine for OpenCV (as of commit
 5e92a777) I get about the same time for either version of CMake.

  3.1.0 : 8m57s
  2.8.12.2  : 8m58s
  3.1.0(/MP): 4m52s
  2.8.12.2 (/MP): 4m57s

 Check in your cases that 3.1.0 does not activate additional parts of
 the project that are not built under 2.8.12.

 Also please try a command-line build with just msbuild instead of
 going through cmake --build:

  msbuild ALL_BUILD.vcxproj /p:Configuration=Release
/p:VisualStudioVersion=12.0

 (shouldn't this have been VisualStudioVersion=11.0?)

 So here are the timings:

 3.1.0: 11m52s
 2.8.12: 11m21s

 When keeping an eye on the resource monitor, I can also see that,
 while cmake --build . makes use of all the CPU cores (for 2.8.12) ,
 this is not the case while running msbuild manually.

 Yves
 --

 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:
 http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Creating an installer using cpack

[Hendrik Sattler]

Hi,

on Linux, libraries don't need the executable permission set.

HS


Am 9. Januar 2015 21:30:54 MEZ, schrieb J Decker d3c...@gmail.com:
need to use install( PROGRAMS ... ) then



On Fri, Jan 9, 2015 at 7:52 AM, Gonzalo Garramuno ggarr...@gmail.com
wrote:

 On 08/01/15 21:56, J Decker wrote:

 I don't think you should install libraries like that... things in
binary
 would be build products, can you possibly just install the libs as
normal

 INSTALL( Target ... LIBRARY DESTINATION lib )

 The lib files are not built by cmake but are dependencies for my
program.

 The lib files are symbolic links to the /usr/local/lib directory. For
 example:

 Release/lib/libfltk2.so.2.0 - /usr/local/lib/libfltk2.so.2.0

 With the tgz installer, the symlinks are flattened to their
respective
 files.
 However, with the deb installer, the symlinks are kept.
 I would like the symlink to be flattened also in the deb installer.
Then
 all would be peachy.

 install( PROGRAM  ) will keep executable permissions...  (as
opposed
to using FILES or DIRECTORY )  not sure about symlinks

http://www.cmake.org/cmake/help/v3.0/command/install.html only
references
symbolic links once, and that's for Install( TARGET ... )  Either
NAMELINK_ONLY or NAMELINK_SKIP may be specified as a LIBRARY option. On
some platforms a versioned shared library has a symbolic link such as:

-- 

 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:
 http://public.kitware.com/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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Get native build command with CMake 3+

[Hendrik Sattler]

Hi,

this original makefile rule was probably just a simplification.
Make your custom target depend on all example targets which link the desired 
parts, then you get what the original makefile author just didn't want to do 
manually: having built all examples and their dependencies.
And it's less ugly...

HS


Am 5. Dezember 2014 11:46:03 MEZ, schrieb Petr Kmoch petr.km...@gmail.com:
Hi all.

I'm converting a small Makefile-based project to CMake. The project is
not
mine, so I am trying to match its existing buildsystem as closely as
possible.

One of the rules in the original Makefile is (simplified) as follows:

examples: all
  make -C example_dir all

This gives a target 'examples' in the top-level Makefile, which is not
included in 'all', but can be used to build all examples. I would like
to
achieve something similar with CMake.

I added example_dir/CMakeLists.txt, which includes a project() command
and
defines all the targets for example executables. In the toplevel
CMakeList,
I did this:

# Add the subdirectory but don't include its targets by default
add_subdirectory(example_dir EXCLUDE_FROM_ALL)

# Add a custom target to build all examples
add_custom_target(examples ???)

I'm stuck at the custom target. What I need for its command is a
generator-agnostic equivalent for 'make -C example_dir all' (or 'make
-f
example_dir/Makefile all').

I tried 'cmake --build ${CMAKE_CURRENT_BINARY_DIR}/example_dir ...',
but
this complains that example_dir does not contain a CMakeCache.txt
(which is
correct of course, it's not the toplevel directory). Then I remembered
that
build_command() can be used to get a command line to build a project;
unfortunately, in 3.0 and later, this just returns 'cmake --build ...'
and
so is unusable in my situation.

Is there a way to query CMake for the native command line (or something
else) I could use to build the CMake-generated buildsystem in the
subdirectory? I thought a bit about CMAKE_MAKE_PROGRAM, but that
doesn't
tell me anything about what arguments I should pass, and it's not even
set
on Visual Studio generators.

As a workaround, I thought of not doing add_subdirectory() at all and
instead adding a custom target with 'ctest --build-and-test ...', but I
would prefer to configure  generate the two directories together. I
plan
to eventually add install() rules for the examples as well, and the
examples also use one of the targets from the toplevel cmakelist in
add_custom_command(OUTPUT ...), so I would really like to keep them as
one
CMake system. Is there a way to do so?

Petr




-- 

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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake