[Cmake-commits] CMake branch, master, updated. v3.13.0-rc1-101-gfd71ad3
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via fd71ad37152d2d3b843fc491abb2202e155c0114 (commit) from 7bacb2295583f1a0e04a7312c370064310b1834b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fd71ad37152d2d3b843fc491abb2202e155c0114 commit fd71ad37152d2d3b843fc491abb2202e155c0114 Author: Kitware Robot AuthorDate: Sat Oct 13 00:01:08 2018 -0400 Commit: Kitware Robot CommitDate: Sat Oct 13 00:01:08 2018 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 1bc2632..43b81a8 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 13) -set(CMake_VERSION_PATCH 20181012) +set(CMake_VERSION_PATCH 20181013) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
Re: [cmake-developers] Current Projects
On Fri, 2018-10-12 at 14:01 -0700, George Blikas wrote: > I was looking to be a more serious contributor to CMake. Is there a > list of feature requests, or a simple enough project that I could get > started on? Hello George, Thank you for your interest in contributing to CMake! We're always happy to have new developers. If you're looking to implement feature requests or fix bugs, I'd start with the official CMake issue tracker on our GitLab server: https://git lab.kitware.com/cmake/cmake/issues Pick something that looks interesting and take a crack at it! We are very responsive to merge requests. In addition, if there's a feature or behavior tweak you want to see for your own personal use, you could try implementing it yourself. If you have an exotic hardware/software platform that we don't currently support, you could try porting it to that architecture and setting up your machine as a nightly testing machine. Thanks again, Kyle -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] Building arguments to target_comple_definitions()
> So in CMake parlance, what type is the last argument to > target_compile_definitions? Is it a list, string or something else? > It's a series of VISIBILITY_SPECIFIER DEF1 DEF2 ... DEFN, so the visibility specifier followed by a list of definitions, optionally followed by another visibility specifier and list of definitions, etc. add_library(Foo OBJECT Foo.cxx) target_compile_definitions(Foo PUBLIC COMMON_DEF_1 COMMON_DEF_2 PRIVATE FOO_SPECIFIC_DEF=42 ) will translate to something like: c++ -DCOMMON_DEF_1 -DCOMMON_DEF_2 -DFOO_SPECIFIC_DEF=4 -o Foo.cxx.o -c Foo.cxx - Chuck > > *From: *Chuck Atkins > *Date: *Thursday, October 11, 2018 at 2:55 PM > *To: *Rob Boehne > *Cc: *CMake Mail List > *Subject: *Re: [CMake] Building arguments to target_comple_definitions() > > > > So, are you suggesting that I make a “dummy” target and fill it with the > common options in compile_definitions() and include_directories() (et. al.) > > Then make my OBJECT libraries (and the shared library) depend on the > “dummy” target? > > > > If that’s not the suggestion, I’m afraid I don’t see how I can use this to > set the common flags > > > > That's certainly one way you can solve the problem, i.e. making an > interface library with the common defs, and a good idea at that, but that's > not what I was referring to. I was simply tying to explain that the error > your getting trying to pass arguments to target_compile_options is because > you're missing the visibility argument. > > > > - Chuck > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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] Putting the git commit hash in a cmake variable
Sorry if this shows up oddly on the list; I was forwarded the original
in order to reply. As such, please keep me in Cc.
> I'd like to set a CMake variable to the current git commit short hash.
> This variable will be used as part of the version string for my
> project (ex: "1.0.1+git.${SHORT_HASH}"). I can get at this short hash
> by using execute_process and setting the resulting output to a
> variable.
>
> ```cmake
> execute_process(
> COMMAND
> git rev-parse --short HEAD
> RESULT_VARIABLE
> SHORT_HASH_RESULT
> OUTPUT_VARIABLE
> SHORT_HASH)
> ```
>
> My issue is that cmake will only run execute_process once, during the
> configure step. I need cmake to run this execute_process on every
> build and, if the output has changed, reconfigure to make sure
> SHORT_HASH is up to date.
>
> I came up with one solution to this issue: During the configure step,
> I can write the current short hash to a file named short_hash.txt. On
> every build, I'll re-compute the short hash and verify that the
> computed short hash is the same as what is in short_hash.txt. If its
> not, I'll write the new short hash to short_hash.txt. I then make
> short_hash.txt an input to configure_file. This will cause cmake to
> validate SHORT_HASH is properly set, and re-configure if its not.
I solved this a few years ago :) . Here are all the relevant files:
https://github.com/Kitware/sprokit/blob/master/src/sprokit/version.h.in
https://github.com/Kitware/sprokit/blob/master/src/sprokit/.gitattributes
https://github.com/Kitware/sprokit/blob/master/src/sprokit/CMakeLists.txt
https://github.com/Kitware/sprokit/blob/master/conf/sprokit-macro-configure.cmake
Basically the solution follows:
- If we're in an archive (.gitattributes' export-subst), use the
information from it. Detect this in CMake by checking if Git
replaced substitutions for us:
if ("$Format:$" STREQUAL "")
If we are, just use that information (gathered using other
`$Format:$` expansions).
- If not, we set up some code to run at build time to extract the
information.
- The variables (or code) from above is injected via
`sprokit_configure_file_always` which basically is just a
`configure_file` done at build time. The list of variables to export
to the script are listed as arguments. The `_always` bit just adds
an extra output file named `${output}.noexist` which causes tools to
always run the associated custom command (which is then attached to
a custom target via its output file).
The file is only updated if the contents change (via `configure_file`),
so rebuilding should be minimal.
--Ben
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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-commits] CMake branch, master, updated. v3.13.0-rc1-100-g7bacb22
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 7bacb2295583f1a0e04a7312c370064310b1834b (commit) via 1cfe2442c4196e592a6d99c7a2a4f5aa94038a78 (commit) via f76047f34a960272ca29518551fb23504c61ee7e (commit) via 3b80cd77fb3e1d0ee6a77a590830e7dc620df1a5 (commit) from 0d8a4ded12f621a410b60117a64b7842649f0d1d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7bacb2295583f1a0e04a7312c370064310b1834b commit 7bacb2295583f1a0e04a7312c370064310b1834b Merge: 1cfe244 3b80cd7 Author: Brad King AuthorDate: Fri Oct 12 12:17:51 2018 + Commit: Kitware Robot CommitDate: Fri Oct 12 08:17:58 2018 -0400 Merge topic 'cppcheck-exit-code' 3b80cd77fb Fail the build if cppcheck returns a non-zero exit code Acked-by: Kitware Robot Merge-request: !2459 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1cfe2442c4196e592a6d99c7a2a4f5aa94038a78 commit 1cfe2442c4196e592a6d99c7a2a4f5aa94038a78 Merge: 0d8a4de f76047f Author: Brad King AuthorDate: Fri Oct 12 12:15:17 2018 + Commit: Kitware Robot CommitDate: Fri Oct 12 08:15:25 2018 -0400 Merge topic 'find_libinput' f76047f34a FindLibinput: Add module to find libinput Acked-by: Kitware Robot Merge-request: !2420 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f76047f34a960272ca29518551fb23504c61ee7e commit f76047f34a960272ca29518551fb23504c61ee7e Author: Frederik Gladhorn AuthorDate: Thu Sep 27 09:41:02 2018 +0200 Commit: Brad King CommitDate: Thu Oct 11 10:43:45 2018 -0400 FindLibinput: Add module to find libinput This module is inspired by one from KDE's KWin. diff --git a/Copyright.txt b/Copyright.txt index 743c634..0b0fbf1 100644 --- a/Copyright.txt +++ b/Copyright.txt @@ -39,6 +39,7 @@ The following individuals and institutions are among the Contributors: * Alexander Neundorf * Alexander Smorkalov * Alexey Sokolov +* Alex Merry * Alex Turbov * Andreas Pakulat * Andreas Schneider @@ -65,6 +66,7 @@ The following individuals and institutions are among the Contributors: * Kelly Thompson * Konstantin Podsvirov * Mario Bensi +* Martin Gräßlin * Mathieu Malaterre * Matthaeus G. Chajdas * Matthias Kretz diff --git a/Help/manual/cmake-modules.7.rst b/Help/manual/cmake-modules.7.rst index af8e33f..f9b4afb 100644 --- a/Help/manual/cmake-modules.7.rst +++ b/Help/manual/cmake-modules.7.rst @@ -165,6 +165,7 @@ They are normally called through the :command:`find_package` command. /module/FindLAPACK /module/FindLATEX /module/FindLibArchive + /module/FindLibinput /module/FindLibLZMA /module/FindLibXml2 /module/FindLibXslt diff --git a/Help/module/FindLibinput.rst b/Help/module/FindLibinput.rst new file mode 100644 index 000..a8ca0b0 --- /dev/null +++ b/Help/module/FindLibinput.rst @@ -0,0 +1 @@ +.. cmake-module:: ../../Modules/FindLibinput.cmake diff --git a/Help/release/dev/find_libinput.rst b/Help/release/dev/find_libinput.rst new file mode 100644 index 000..ebb9e7a --- /dev/null +++ b/Help/release/dev/find_libinput.rst @@ -0,0 +1,6 @@ +find_libinput +- + +* The :module:`FindLibinput` module was added to find `libinput`_. + +.. _`libinput`: https://www.freedesktop.org/wiki/Software/libinput/ diff --git a/Modules/FindLibinput.cmake b/Modules/FindLibinput.cmake new file mode 100644 index 000..df66cff --- /dev/null +++ b/Modules/FindLibinput.cmake @@ -0,0 +1,83 @@ +# Distributed under the OSI-approved BSD 3-Clause License. See accompanying +# file Copyright.txt or https://cmake.org/licensing for details. + +#[===[.rst: +FindLibinput + + +Find libinput headers and library. + +Imported Targets + + +``Libinput::Libinput`` + The libinput library, if found. + +Result Variables + + +This will define the following variables in your project: + +``Libinput_FOUND`` + true if (the requested version of) libinput is available. +``Libinput_VERSION`` + the version of libinput. +``Libinput_LIBRARIES`` + the libraries to link against to use libinput. +``Libinput_INCLUDE_DIRS`` + where to find the libinput headers. +``Libinput_DEFINITIONS`` + this should be passed to target_compile_options(), if the + target is not used for linking + +#]===] + + +# Use pkg-config to get the directories and then use these values +# in the FIND_PATH() and FIND_LIBRARY() calls +find_package(PkgConfig QUIET)
[Cmake-commits] CMake branch, release, updated. v3.13.0-rc1-13-g769fc9c
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, release has been updated via 769fc9c4de2daad3b6c935d51e46bacc85131176 (commit) via 9c75922745d1d856fe35763ff1bafe68979ab70b (commit) via c9b7cd8ed719cb2f514aa98ecc422056cf4d4a91 (commit) via e23c41ba785c0b53dee325cf4697ae7293eddbb2 (commit) via d26f5b68895b71c53d8ba3a77d1a99fbdd0decd3 (commit) via 0f48fbaa72fa254faaed6b586fcaa5d3c5c77798 (commit) from bcfb2457030efcfdb84eef02230aa47f18072555 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - --- Summary of changes: Help/command/install.rst | 4 --- Help/release/3.13.rst| 3 -- Modules/FindBoost.cmake | 1 + Modules/FindPython/Support.cmake | 35 +-- Modules/FindPythonLibs.cmake | 44 Source/cmInstallScriptGenerator.cxx | 40 + Source/cmInstallScriptGenerator.h| 13 +-- Tests/RunCMake/install/CODE-genex-bad-result.txt | 1 - Tests/RunCMake/install/CODE-genex-bad-stderr.txt | 6 Tests/RunCMake/install/CODE-genex-bad.cmake | 1 - Tests/RunCMake/install/CODE-genex-check.cmake| 7 Tests/RunCMake/install/CODE-genex.cmake | 2 -- Tests/RunCMake/install/RunCMakeTest.cmake| 2 -- 13 files changed, 87 insertions(+), 72 deletions(-) delete mode 100644 Tests/RunCMake/install/CODE-genex-bad-result.txt delete mode 100644 Tests/RunCMake/install/CODE-genex-bad-stderr.txt delete mode 100644 Tests/RunCMake/install/CODE-genex-bad.cmake delete mode 100644 Tests/RunCMake/install/CODE-genex-check.cmake delete mode 100644 Tests/RunCMake/install/CODE-genex.cmake hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.13.0-rc1-96-g0d8a4de
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via 0d8a4ded12f621a410b60117a64b7842649f0d1d (commit)
via ced094e22e1c94da249990668d106a80faaeab57 (commit)
via 02eb3c302a71210b375a6b4f9ae604c5e5dafe02 (commit)
via 769fc9c4de2daad3b6c935d51e46bacc85131176 (commit)
via c9b7cd8ed719cb2f514aa98ecc422056cf4d4a91 (commit)
via e23c41ba785c0b53dee325cf4697ae7293eddbb2 (commit)
via fd0e40f1667ed7e835d5a6fcbcf3b4d6489dff2c (commit)
via d26f5b68895b71c53d8ba3a77d1a99fbdd0decd3 (commit)
via 0f48fbaa72fa254faaed6b586fcaa5d3c5c77798 (commit)
from e9eaf0f262543db6d458956bfa3d5da7edfb9744 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0d8a4ded12f621a410b60117a64b7842649f0d1d
commit 0d8a4ded12f621a410b60117a64b7842649f0d1d
Merge: ced094e 769fc9c
Author: Brad King
AuthorDate: Fri Oct 12 08:12:49 2018 -0400
Commit: Brad King
CommitDate: Fri Oct 12 08:12:49 2018 -0400
Merge branch 'release-3.13'
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ced094e22e1c94da249990668d106a80faaeab57
commit ced094e22e1c94da249990668d106a80faaeab57
Merge: 02eb3c3 fd0e40f
Author: Brad King
AuthorDate: Fri Oct 12 12:11:42 2018 +
Commit: Kitware Robot
CommitDate: Fri Oct 12 08:11:49 2018 -0400
Merge topic 'revert-install-code-script-genex'
fd0e40f166 Merge branch 'backport-revert-install-code-script-genex' into
revert-install-code-script-genex
0f48fbaa72 install: Revert CODE,SCRIPT support for generator expressions
Acked-by: Kitware Robot
Merge-request: !2474
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=02eb3c302a71210b375a6b4f9ae604c5e5dafe02
commit 02eb3c302a71210b375a6b4f9ae604c5e5dafe02
Merge: e9eaf0f e23c41b
Author: Brad King
AuthorDate: Fri Oct 12 12:09:25 2018 +
Commit: Kitware Robot
CommitDate: Fri Oct 12 08:09:37 2018 -0400
Merge topic 'FindPython-updates'
e23c41ba78 FindPython*: Add missing registry paths
Acked-by: Kitware Robot
Merge-request: !2476
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fd0e40f1667ed7e835d5a6fcbcf3b4d6489dff2c
commit fd0e40f1667ed7e835d5a6fcbcf3b4d6489dff2c
Merge: e2dd6ac 0f48fba
Author: Brad King
AuthorDate: Thu Oct 11 08:14:48 2018 -0400
Commit: Brad King
CommitDate: Thu Oct 11 08:14:48 2018 -0400
Merge branch 'backport-revert-install-code-script-genex' into
revert-install-code-script-genex
diff --cc Source/cmInstallScriptGenerator.cxx
index 1d7784e,f7e6e44..7d77b7c
--- a/Source/cmInstallScriptGenerator.cxx
+++ b/Source/cmInstallScriptGenerator.cxx
@@@ -27,37 -22,18 +22,18 @@@ cmInstallScriptGenerator::~cmInstallScr
{
}
- void cmInstallScriptGenerator::Compute(cmLocalGenerator* lg)
+ void cmInstallScriptGenerator::GenerateScript(std::ostream& os)
{
- this->LocalGenerator = lg;
- }
+ Indent indent;
+ std::string component_test =
+ this->CreateComponentTest(this->Component.c_str(), this->ExcludeFromAll);
+ os << indent << "if(" << component_test << ")\n";
- void cmInstallScriptGenerator::AddScriptInstallRule(std::ostream& os,
- Indent indent,
- std::string const& script)
- {
if (this->Code) {
- os << indent << script << "\n";
- } else {
- os << indent << "include(\"" << script << "\")\n";
- }
- }
-
- void cmInstallScriptGenerator::GenerateScriptActions(std::ostream& os,
- Indent indent)
- {
- if (this->ActionsPerConfig) {
- this->cmInstallGenerator::GenerateScriptActions(os, indent);
-os << indent.Next() << this->Script << "\n";
++os << indent << this->Script << "\n";
} else {
- this->AddScriptInstallRule(os, indent, this->Script);
-os << indent.Next() << "include(\"" << this->Script << "\")\n";
++os << indent << "include(\"" << this->Script << "\")\n";
}
- }
- void cmInstallScriptGenerator::GenerateScriptForConfig(
- std::ostream& os, const std::string& config, Indent indent)
- {
- cmGeneratorExpression ge;
- std::unique_ptr cge = ge.Parse(this->Script);
- this->AddScriptInstallRule(os, indent,
- cge->Evaluate(this->LocalGenerator, config));
+ os << indent << "endif()\n\n";
}
---
Summary of changes:
Help/command/install.rst | 4 ---
Help/release/3.13.rst| 3 --
Modules/FindPython/Support.cmake
[Cmake-commits] CMake branch, master, updated. v3.13.0-rc1-87-ge9eaf0f
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via e9eaf0f262543db6d458956bfa3d5da7edfb9744 (commit)
via 9c75922745d1d856fe35763ff1bafe68979ab70b (commit)
from aeb24db55400b16c9d53d10b50cdb4668ba93e5f (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e9eaf0f262543db6d458956bfa3d5da7edfb9744
commit e9eaf0f262543db6d458956bfa3d5da7edfb9744
Merge: aeb24db 9c75922
Author: Brad King
AuthorDate: Fri Oct 12 11:52:40 2018 +
Commit: Kitware Robot
CommitDate: Fri Oct 12 07:53:00 2018 -0400
Merge topic 'FindBoost-mt-release'
9c75922745 FindBoost: Search for -mt variant of release libs
Acked-by: Kitware Robot
Merge-request: !2475
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9c75922745d1d856fe35763ff1bafe68979ab70b
commit 9c75922745d1d856fe35763ff1bafe68979ab70b
Author: Mario Bielert
AuthorDate: Thu Oct 11 11:31:21 2018 -0400
Commit: Brad King
CommitDate: Thu Oct 11 14:16:34 2018 -0400
FindBoost: Search for -mt variant of release libs
We were searching the `-mt` variant for debug libs only.
It makes sense for release libs too.
diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 37539ba..5090c60 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -1740,6 +1740,7 @@ foreach(COMPONENT ${Boost_FIND_COMPONENTS})
list(APPEND _boost_RELEASE_NAMES
${Boost_LIB_PREFIX}${Boost_NAMESPACE}_${component}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}${_boost_ARCHITECTURE_TAG}-${Boost_LIB_VERSION}
${Boost_LIB_PREFIX}${Boost_NAMESPACE}_${component}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}
+ ${Boost_LIB_PREFIX}${Boost_NAMESPACE}_${component}${_boost_MULTITHREADED}
${Boost_LIB_PREFIX}${Boost_NAMESPACE}_${component} )
if(_boost_STATIC_RUNTIME_WORKAROUND)
set(_boost_RELEASE_STATIC_ABI_TAG "-s${_boost_RELEASE_ABI_TAG}")
---
Summary of changes:
Modules/FindBoost.cmake | 1 +
1 file changed, 1 insertion(+)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits
Re: [CMake] Controlling order of includes with INTERFACE_INCLUDE_DIRECTORIES for an IMPORTED target
> what version of CMake are you using?
I'm using cmake version 3.10.0.
> Which seems at odds with your observations/comments, unless I'm
> misunderstanding what you're saying.
Well, what's for sure is that the above invocation does not compile,
but if at our root CMakeLists.txt we add
include_directories(/apps/homefs1/USER/work/.../libllvm/icc/include)
so that the invocation is now :
g++ ... -I/apps/homefs1/USER/work/. -I. -isystem
/apps/homefs1/USER/work/.../libllvm/icc/include -isystem
/spare/local/USER/conda_root/envs/gcc6cxx14/include ...
it compiles fine.
Actually, what's odd is that the path that's being added by
set_property(TARGET global_llvm_external APPEND PROPERTY
INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_CURRENT_SOURCE_DIR}/icc/include)
does not materialize with
-I/apps/homefs1/USER/work/.../libllvm/icc/include
but with
-isystem/apps/homefs1/USER/work/.../libllvm/icc/include
So if -isystem are searched last, then if there's a way to tweak
INTERFACE_INCLUDE_DIRECTORIES to use -I instead of -isystem that would
also work.
David
On Fri, Oct 12, 2018 at 9:02 AM Craig Scott wrote:
>
>
>
> On Fri, Oct 12, 2018 at 6:42 PM David Jobet wrote:
>>
>> Hello,
>>
>> we embed in our source a copy of an ICC build of LLVM, that we import :
>>
>> add_library(global_llvm_external STATIC IMPORTED)
>> set_property(TARGET global_llvm_external APPEND PROPERTY
>> INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_CURRENT_SOURCE_DIR}/icc/include)
>> set_property(TARGET global_llvm_external APPEND PROPERTY
>> IMPORTED_LOCATION ${CMAKE_CURRENT_SOURCE_DIR}/icc/lib/libLLVMCore.a)
>> set_property(TARGET global_llvm_external APPEND PROPERTY
>> INTERFACE_LINK_LIBRARIES
>> ${CMAKE_CURRENT_SOURCE_DIR}/icc/lib/libLLVMLTO.a ...)
>>
>> add_library(global_llvm INTERFACE)
>> target_link_libraries(global_llvm INTERFACE global_llvm_external)
>> add_library(global::llvm ALIAS global_llvm)
>>
>> It works fine, until someone decided to install a more recent version
>> of LLVM in its development env. (which is not ABI compatible)
>>
>> Somehow, system includes path are looked into first
>> g++ ... -I/apps/homefs1/USER/work/. -I. -isystem
>> /spare/local/USER/conda_root/envs/gcc6cxx14/include -isystem
>> /apps/homefs1/USER/work/.../libllvm/icc/include ...
>>
>> so, as with include_directories where it's possible to control the
>> ordering with BEFORE or AFTER, is there a way to tell cmake that when
>> linking against global::llvm we want the include directories needed by
>> global::llvm to be prepended (instead of appended) ?
>>
>
> While not directly answering your question, what version of CMake are you
> using? There was a change related to this area in the following merge request
> that went in for the 3.12 release:
>
> https://gitlab.kitware.com/cmake/cmake/merge_requests/1968
>
> The part that got my attention is the following claim in the description:
>
>> An effect of the -isystem flag is to search the directory after those
>> specified via -I flags.
>
>
> Which seems at odds with your observations/comments, unless I'm
> misunderstanding what you're saying.
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> New book released: Professional CMake: A Practical Guide
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Controlling order of includes with INTERFACE_INCLUDE_DIRECTORIES for an IMPORTED target
On Fri, Oct 12, 2018 at 6:42 PM David Jobet
wrote:
> Hello,
>
> we embed in our source a copy of an ICC build of LLVM, that we import :
>
> add_library(global_llvm_external STATIC IMPORTED)
> set_property(TARGET global_llvm_external APPEND PROPERTY
> INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_CURRENT_SOURCE_DIR}/icc/include)
> set_property(TARGET global_llvm_external APPEND PROPERTY
> IMPORTED_LOCATION ${CMAKE_CURRENT_SOURCE_DIR}/icc/lib/libLLVMCore.a)
> set_property(TARGET global_llvm_external APPEND PROPERTY
> INTERFACE_LINK_LIBRARIES
> ${CMAKE_CURRENT_SOURCE_DIR}/icc/lib/libLLVMLTO.a ...)
>
> add_library(global_llvm INTERFACE)
> target_link_libraries(global_llvm INTERFACE global_llvm_external)
> add_library(global::llvm ALIAS global_llvm)
>
> It works fine, until someone decided to install a more recent version
> of LLVM in its development env. (which is not ABI compatible)
>
> Somehow, system includes path are looked into first
> g++ ... -I/apps/homefs1/USER/work/. -I. -isystem
> /spare/local/USER/conda_root/envs/gcc6cxx14/include -isystem
> /apps/homefs1/USER/work/.../libllvm/icc/include ...
>
> so, as with include_directories where it's possible to control the
> ordering with BEFORE or AFTER, is there a way to tell cmake that when
> linking against global::llvm we want the include directories needed by
> global::llvm to be prepended (instead of appended) ?
>
>
While not directly answering your question, what version of CMake are you
using? There was a change related to this area in the following merge
request that went in for the 3.12 release:
https://gitlab.kitware.com/cmake/cmake/merge_requests/1968
The part that got my attention is the following claim in the description:
An effect of the -isystem flag is to search the directory after
> those specified via -I flags.
Which seems at odds with your observations/comments, unless I'm
misunderstanding what you're saying.
--
Craig Scott
Melbourne, Australia
https://crascit.com
New book released: Professional CMake: A Practical Guide
[CMake] Controlling order of includes with INTERFACE_INCLUDE_DIRECTORIES for an IMPORTED target
Hello,
we embed in our source a copy of an ICC build of LLVM, that we import :
add_library(global_llvm_external STATIC IMPORTED)
set_property(TARGET global_llvm_external APPEND PROPERTY
INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_CURRENT_SOURCE_DIR}/icc/include)
set_property(TARGET global_llvm_external APPEND PROPERTY
IMPORTED_LOCATION ${CMAKE_CURRENT_SOURCE_DIR}/icc/lib/libLLVMCore.a)
set_property(TARGET global_llvm_external APPEND PROPERTY
INTERFACE_LINK_LIBRARIES
${CMAKE_CURRENT_SOURCE_DIR}/icc/lib/libLLVMLTO.a ...)
add_library(global_llvm INTERFACE)
target_link_libraries(global_llvm INTERFACE global_llvm_external)
add_library(global::llvm ALIAS global_llvm)
It works fine, until someone decided to install a more recent version
of LLVM in its development env. (which is not ABI compatible)
Somehow, system includes path are looked into first
g++ ... -I/apps/homefs1/USER/work/. -I. -isystem
/spare/local/USER/conda_root/envs/gcc6cxx14/include -isystem
/apps/homefs1/USER/work/.../libllvm/icc/include ...
so, as with include_directories where it's possible to control the
ordering with BEFORE or AFTER, is there a way to tell cmake that when
linking against global::llvm we want the include directories needed by
global::llvm to be prepended (instead of appended) ?
With regards
David
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Putting the git commit hash in a cmake variable
Den fre 12 okt. 2018 00:24Matt Schulte skrev:
> Ah, that's a good tip Elvis. The CONFIGURE_DEPENDS on the .git/index
> would do the trick. I can set that up for now.
>
> In the long run, its not that ideal because it forces a reconfigure on
> every commit (which is annoying for developers at their desk).
>
> My example above is actually a little more complex in real life. I
> just simplified it for this e-mail. We only append the git hash to our
> version string if we are on certain branches. So our version string
> doesn't change on feature branches.
>
> For now I think we'll bite the bullet and re-configure on every
> commit. I'll keep mulling over the how to set this up. Thanks for the
> idea!
>
Yes, I should have mentioned this downside. In our case it was acceptable
as our configuration step is rather quick.
Tangential note from me re. developer experience: Yesterday I tried out
zapcc for local development, and it really is fast:
https://github.com/yrnkrn/zapcc
Takes a bit of memory of course.
Elvis
>
> -Matt
> On Thu, Oct 11, 2018 at 12:26 PM Chuck Atkins
> wrote:
> >
> >
> >> COMMAND "${GIT_EXECUTABLE}" describe --always HEAD
> >
> >
> > git describe is nice way to do it since you can get a monotonic-ish
> increasing version number
> >
> >
> >>
> >> string(REGEX REPLACE "^.*-(.*)-g.*$" "\\1" MYAPP_VERSION_MICRO
> "${MYAPP_VERSION}")
> >> ...
> >> set(MYAPP_VERSION_MICRO "0")
> >
> >
> > Only tangentially related, CMake commands and functions that deal with
> version information refer to the 4th component as _TWEAK.
> >
> > - Chuck
> >
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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
