Re: [CMake] How to get message() to go to stdout when executed from -P?
>From the Windows command line, you would do it with 2>&1 after the command (2 >is stderr, and 1 is stdout). You could write your custom command as a batch >file or bash script (unfortunately platform dependent) which uses this >technique with a single command inside the batch file. HTH, David C. > On Apr 10, 2017, at 6:44 PM, Robert Dailey wrote: > > When I execute a CMake script as a custom command, message() logs are > not shown in stdout from that script. > > Is there a way to make it pipe out messages? > -- > > 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
[CMake] How to get message() to go to stdout when executed from -P?
When I execute a CMake script as a custom command, message() logs are not shown in stdout from that script. Is there a way to make it pipe out messages? -- 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] [ANNOUNCE] CMake 3.8.0 available for download
I am proud to announce that CMake 3.8.0 is now available for download at:
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.8
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.8/release/3.8.html
Some of the more significant changes in CMake 3.8 are:
* CMake now supports "CSharp" (C#) as a first-class language. It is
currently supported by the Visual Studio Generators for VS 2010
and above.
* CMake now supports "CUDA" as a first-class language. It is
currently supported by the Makefile Generators and the
"Ninja" generator on Linux, macOS, and Windows. Support for the
Visual Studio IDE is under development but not included in this
release.
* The "Compile Features" functionality now offers meta-features that
request compiler modes for specific language standard levels (e.g.
"cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and
"CMAKE_CXX_KNOWN_FEATURES".
* The "Compile Features" functionality is now aware of C++ 17. No
specific features are yet enumerated besides the "cxx_std_17" meta-
feature.
* The Visual Studio Generators for VS 2013 and above learned to
support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value
(e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit
toolchain on 64-bit hosts.
* The Visual Studio Generators learned to treat files passed to
"target_link_libraries()" whose names end in ".targets" as MSBuild
"targets" files to be imported into generated project files.
* The "try_compile()" command source file signature gained new
options to specify the language standard to use in the generated
test project.
* The "try_compile()" command source file signature now honors
language standard variables like "CMAKE_CXX_STANDARD". See policy
"CMP0067".
* A "BUILD_RPATH" target property and corresponding
"CMAKE_BUILD_RPATH" variable were added to support custom "RPATH"
locations to be added to binaries in the build tree.
* The "COMPILE_FLAGS" source file property learned to support
"generator expressions".
* A new generator expression "$" was
added. It resolves to the true-value if the condition is "1" and
resolves to the false-value if the condition is "0".
* The "Compile Features" functionality is now aware of features
supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX
and Windows platforms.
* The Visual Studio Generators for VS 2010 and above now place per-
source file flags after target-wide flags when they are classified
as raw flags with no project file setting ("AdditionalOptions").
This behavior is more consistent with the ordering of flags produced
by other generators, and allows flags on more-specific properties
(per-source) to override those on more general ones (per-target).
* The precompiled Windows binary MSI package provided on "cmake.org"
now records the installation directory in the Windows Registry under
the key "HKLM\Software\Kitware\CMake" with a value named
"InstallDir".
CMake 3.8 Release Notes
***
Changes made since CMake 3.7 include the following.
New Features
Languages
-
C#
~~
* CMake learned to support "CSharp" (C#) as a first-class language
that can be enabled via the "project()" and "enable_language()"
commands. It is currently supported by the Visual Studio Generators
for VS 2010 and above.
C# assemblies and programs can be added just like common C++ targets
using the "add_library()" and "add_executable()" commands.
References between C# targets in the same source tree may be
specified by "target_link_libraries()" like for C++. References to
system or 3rd-party assemblies may be specified by the target
properties "VS_DOTNET_REFERENCE_" and
"VS_DOTNET_REFERENCES".
* More fine tuning of C# targets may be done using target and source
file properties. Specifically the target properties related to
Visual Studio ("VS_*") are worth a look (for setting toolset
versions, root namespaces, assembly icons, ...).
CUDA
* CMake learned to support "CUDA" as a first-class language that can
be enabled via the "project()" and "enable_language()" commands.
* "CUDA" is currently supported by the Makefile Generators and the
"Ninja" generator on Linux, macOS, and Windows. Support for the
Visual Studio IDE is under development but not included in this
release.
* The NVIDIA CUDA Toolkit compiler ("nvcc") is supported.
C & C++
~~~
* The "Compile Features" functionality now offers meta-features that
request compiler modes for specific language standard levels (e.g.
"cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and
"CMAKE_CXX_KNOWN_FEATURES".
* The "Compile Features" functionality is now aware of C++ 17. No
specific features are yet enumerated besides the "cxx_std_17" meta-
feature.
* The "Compile Features" functionality is now aware of the
availability of C99 in gcc since version 3.
Re: [CMake] How to properly handle build version number in CMake script for project
OK weirdly, tested again, this also works and is a little more
simplified (although more confusing, since now we're intermixing
non-cache and cache variables with the same name; behavior is not
exactly clear, or well-defined.
if( BUILD_VERSION )
set( BUILD_VERSION ${BUILD_VERSION} )
unset( BUILD_VERSION CACHE )
else()
set( BUILD_VERSION 7.1.1.2 )
endif()
On Mon, Apr 10, 2017 at 1:32 PM, Robert Dailey wrote:
> Actually this seems to work:
>
> if( BUILD_VERSION )
>
> set( version_override ${BUILD_VERSION} )
> unset( BUILD_VERSION CACHE )
> set( BUILD_VERSION ${version_override} )
> unset( version_override )
>
> else()
>
> set( BUILD_VERSION 7.1.1.2 )
>
> endif()
>
> It's a bit messy but gets the job done, and doesn't require
> configure_file(). Maybe there is a way to clean this up even more?
>
> I noticed that unset( BUILD_VERSION CACHE ) actually unsets non-cache
> versions of a variable too, so I had to use the temporary variable to
> transfer the value.
>
> On Mon, Apr 10, 2017 at 1:15 PM, Robert Dailey
> wrote:
>> Sorry you're right, this isn't working because -D creates a cache
>> entry for the variable, which breaks it.
>>
>> So maybe more ideas on the configure_file() solution would be ideal...
>> unsetting the cache variable might work as well, I have to toy around
>> with this.
>>
>> On Mon, Apr 10, 2017 at 12:48 PM, Bruce Stephens
>> wrote:
>>> On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey
>>> wrote:
Actually I think your idea does work. Why do you think it won't? I'm
using it right now and so far it seems OK.
>>>
>>> I assumed (without testing, admittedly) is that it would fail if
>>> someone used -D to set the value,
>>> then changed some CMakeLists.txt file, then executed the build command
>>> again. I'd expect that
>>> to rerun cmake to update the build files and I'd fear that you'd then
>>> get BUILD_VERSION from
>>> the CMakeLists.txt file rather than the value explicitly set.
>>>
>>> However, I haven't tried it, and maybe it works fine (with the
>>> generators you care about) even without
>>> caching?
--
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
Actually this seems to work:
if( BUILD_VERSION )
set( version_override ${BUILD_VERSION} )
unset( BUILD_VERSION CACHE )
set( BUILD_VERSION ${version_override} )
unset( version_override )
else()
set( BUILD_VERSION 7.1.1.2 )
endif()
It's a bit messy but gets the job done, and doesn't require
configure_file(). Maybe there is a way to clean this up even more?
I noticed that unset( BUILD_VERSION CACHE ) actually unsets non-cache
versions of a variable too, so I had to use the temporary variable to
transfer the value.
On Mon, Apr 10, 2017 at 1:15 PM, Robert Dailey wrote:
> Sorry you're right, this isn't working because -D creates a cache
> entry for the variable, which breaks it.
>
> So maybe more ideas on the configure_file() solution would be ideal...
> unsetting the cache variable might work as well, I have to toy around
> with this.
>
> On Mon, Apr 10, 2017 at 12:48 PM, Bruce Stephens
> wrote:
>> On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey
>> wrote:
>>> Actually I think your idea does work. Why do you think it won't? I'm
>>> using it right now and so far it seems OK.
>>
>> I assumed (without testing, admittedly) is that it would fail if
>> someone used -D to set the value,
>> then changed some CMakeLists.txt file, then executed the build command
>> again. I'd expect that
>> to rerun cmake to update the build files and I'd fear that you'd then
>> get BUILD_VERSION from
>> the CMakeLists.txt file rather than the value explicitly set.
>>
>> However, I haven't tried it, and maybe it works fine (with the
>> generators you care about) even without
>> caching?
--
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
Sorry you're right, this isn't working because -D creates a cache entry for the variable, which breaks it. So maybe more ideas on the configure_file() solution would be ideal... unsetting the cache variable might work as well, I have to toy around with this. On Mon, Apr 10, 2017 at 12:48 PM, Bruce Stephens wrote: > On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey > wrote: >> Actually I think your idea does work. Why do you think it won't? I'm >> using it right now and so far it seems OK. > > I assumed (without testing, admittedly) is that it would fail if > someone used -D to set the value, > then changed some CMakeLists.txt file, then executed the build command > again. I'd expect that > to rerun cmake to update the build files and I'd fear that you'd then > get BUILD_VERSION from > the CMakeLists.txt file rather than the value explicitly set. > > However, I haven't tried it, and maybe it works fine (with the > generators you care about) even without > caching? -- 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
On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey wrote: > Actually I think your idea does work. Why do you think it won't? I'm > using it right now and so far it seems OK. I assumed (without testing, admittedly) is that it would fail if someone used -D to set the value, then changed some CMakeLists.txt file, then executed the build command again. I'd expect that to rerun cmake to update the build files and I'd fear that you'd then get BUILD_VERSION from the CMakeLists.txt file rather than the value explicitly set. However, I haven't tried it, and maybe it works fine (with the generators you care about) even without caching? -- 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
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] How to properly handle build version number in CMake script for project
Actually I think your idea does work. Why do you think it won't? I'm
using it right now and so far it seems OK.
1. On build server, if it overrides it with -D, then it does not set
it by hand. If it doesn't override, it will use the fixed version in
the file
2. On work machines, it's never defined prior, so it sets it with the
fixed version.
On Mon, Apr 10, 2017 at 9:15 AM, Bruce Stephens
wrote:
> On Mon, Apr 10, 2017 at 2:36 PM, Bruce Stephens
> wrote:
>> You could do something like
>>
>> if(NOT "${BUILD_VERSION}")
>> set(BUILD_VERSION 1.2.3.4)
>> endif()
>
>
> That doesn't work at all, come to think of it. I suspect your best bet
> is to handle
> the caching yourself (likely using a file in ${CMAKE_BINARY_DIR} and
> maybe "include(... OPTIONAL)"). That should allow whatever behaviour
> you want.
>
> I note that llvm's builds have the same sort of problem, so whatever
> fix is required
> isn't obvious even to obviously bright people. (That is, when the
> version switched
> from 4.0.0 to 5.0.0 my builds didn't change their version number. I
> had to remove the
> build directory and build again from clean.)
--
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
On Mon, Apr 10, 2017 at 2:36 PM, Bruce Stephens
wrote:
> You could do something like
>
> if(NOT "${BUILD_VERSION}")
> set(BUILD_VERSION 1.2.3.4)
> endif()
That doesn't work at all, come to think of it. I suspect your best bet
is to handle
the caching yourself (likely using a file in ${CMAKE_BINARY_DIR} and
maybe "include(... OPTIONAL)"). That should allow whatever behaviour
you want.
I note that llvm's builds have the same sort of problem, so whatever
fix is required
isn't obvious even to obviously bright people. (That is, when the
version switched
from 4.0.0 to 5.0.0 my builds didn't change their version number. I
had to remove the
build directory and build again from clean.)
--
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
You could do something like
if(NOT "${BUILD_VERSION}")
set(BUILD_VERSION 1.2.3.4)
endif()
On Mon, Apr 10, 2017 at 2:29 PM, Robert Dailey wrote:
> 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?
> --
>
> 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
[CMake] How to properly handle build version number in CMake script for project
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? -- 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
Seems like the solution here is to make COMMENT work
properly/consistently across all generators. That's the point, after
all, right?
On Sat, Apr 8, 2017 at 12:33 AM, Hendrik Sattler
wrote:
> 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] Transitive include and link libraries on imported targets ?
Hello, After googling a bit I found this post which I think describe exactly what I'm facing : https://cmake.org/pipermail/cmake/2016-August/064100.html However I fail to understand the answers. Maybe I'm expecting too much. Basically, I have 2 imported static targets (A and B with B that needs A to compile and link) that I'd like to treat them as "first class cmake citizen". What I mean by that is that if one of my project lib depends on B, then I want both B and A's include directories to be added to my lib's include directories and I want both A and B's lib to be linked against my lib. So far I can use INTERFACE_LINK_LIBRARIES on B to add A's lib, and I guess I can use INTERFACE_INCLUDE_DIRECTORIES to add A's includes, but that won't pull transitive dependencies of A into B. I can use target_link_libraries on an interface of B to add A as described in my first email : that will properly pull any transitive include or libs but that won't make sure that link order is preserved. Please help. David Le 7 avril 2017 15:27:23 GMT+01:00, David Jobet a écrit : >INTERFACE_LINK_LIBRARIES won't work since it won't pull out include >path for dependants. > >Using target_link_libraries() on the imported lib does not work because >"it is not built". > >So the question remains open : how to represent include and link >dependencies between 2 imported libs ? > >With regards, > >David > >PS : as to why I had to have 2 stages (A_imported and A), this is >because I wanted to add an alias which is not possible on an imported >target > >Le 7 avril 2017 12:32:52 GMT+01:00, David Jobet a >écrit : >>Well not quite. >>I tried that, but my current definition is rather >>Target_link_libraries(B interface B_imported) >> >>I don't remember for which reason I had to do it in 2 stages like that >>(the A/A_imported and B/B_imported versions) >> >>If I add A in the list to read : >>Target_link_libraries(B interface B_imported A) >> >>Then linking against B does add B_imported and A, but it does not keep >>the link order and might put B_imported before A on the command line. >> >>I'll try with property INTERFACE_LINK_LIBRARIES instead, and will also >>try to remove those 2 stages... >> >>With regards >> >>David >> >>Le 6 avril 2017 05:11:46 GMT+01:00, Dvir Yitzchaki >> a écrit : >>>target_link_libraries(B INTERFACE A) >>> >>>Regards, >>>Dvir >>> >>>From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of David Jobet >>>Sent: Wednesday, April 5, 2017 18:34 >>>To: cmake@cmake.org >>>Subject: [CMake] Transitive include and link libraries on imported >>>targets ? >>> >>>Hello, >>> >>>Let's say I build some external libs A and B with B depending on A. >>>B and A do not use cmake, so I build them and install them in a >>>3rdparty directory. I now have access to includes and libs. >>>I then create some cmake file to describe those libs so I can use >them >>>in my project : >>>Add_library(A_imported STATIC imported) >>>Set_property(TARGET A_imported APPEND PROPERTY >>>INTERFACE_INCLUDE_DIRECTORIES 3rdparty/include/A) >>>Set_property(TARGET A_imported APPEND PROPERTY IMPORTED_LOCATION >>>3rdparty/libs/libA.a) >>>Add_library(A INTERFACE) >>>Target_link_library(A INTERFACE A_imported) >>> >>>Same thing for B >>> >>>Now let's say I create a top-level target T that depends on B. >>>Compilation might fail because B might include files from A and A is >>>currently not a dependency of T. >>> >>>I can fix it in 2 ways : >>>1- add A as a dependency of T, but I will need to do it on all my Ts >>>2- somehow make B have transitive dependencies for include and link >on >>>A. That would be my prefered choice... But I don't know how to do it. >>> >>>Is it possible ? How ? >>> >>>Tx for your help. >>> >>>David >> >>-- >>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez >excuser >>ma brièveté. > >-- >Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser >ma brièveté. -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.-- 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
