Re: [CMake] set_directory_properties ADDITIONAL_MAKE_CLEAN_FILES globbing pattern?

Is this just not possible? On 24 August 2016 at 11:35, Steve Lorimer wrote: > As part of our build process we tag certain binary files with version > information such as git branch, number of commits, build variant etc. > > Eg, for a binary called "app" we could install

[Cmake-commits] CMake branch, master, updated. v3.6.1-823-gd5bdcee

_VERSION_MINOR 6) -set(CMake_VERSION_PATCH 20160831) +set(CMake_VERSION_PATCH 20160901) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [cmake-developers] [CMake] Setup/tear down steps for CTest

Actually, we can't really re-use the RESOURCE_LOCK for the proposed RESOURCE_SETUP and RESOURCE_CLEANUP functionality since that would force all the tests using that resource to be serialised. So yes, a separate GROUP or something similar would seem to be needed. Let me amend my earlier proposal

Re: [cmake-developers] [CMake] Setup/tear down steps for CTest

On Tue, Aug 23, 2016 at 4:00 PM, Rolf Eike Beer wrote: > Am Dienstag, 23. August 2016, 10:06:01 schrieb Craig Scott: > > Cheeky way to get me more involved in contributing, but okay, I'll bite. > ;) > > Switching discussion to the dev list. > > > > So how would you want the

Re: [cmake-developers] [CMake] Setup/tear down steps for CTest

In my original thinking, I was of the view that if a setup/cleanup step needed to be executed for each test rather than for the overall test run as a whole, then perhaps the test itself should handle that rather than CMake. The existing RESOURCE_LOCK functionality could then be used to prevent

Re: [cmake-developers] Android.mk

thanks! very cool. go brad go! build via toolchain didn't fly with my former employer. they required the code tree to be built by actual honest to god Android.mk files. don't ask me wy. companies do funny things sometimes. On Wed, Aug 31, 2016 at 8:51 AM, Brad King

[Cmake-commits] CMake branch, next, updated. v3.6.1-1668-gd9fa27a

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, next has been updated via d9fa27a6b1a4088095d8f20da8ca0542a857e989 (commit) via

[cmake-developers] Android.mk

is anyone working on a generator for Android.mk files? i recently parted ways with a company that could have benefited mightily from the feature. i'm not planning to take up anything new for a while. so i might be able to contribute. maybe get a brain dump from someone who's thought about the

[Cmake-commits] CMake branch, next, updated. v3.6.1-1666-gc2addd1

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, next has been updated via c2addd198fc7d6b417fa25e28d2d1f127e1e3288 (commit) via

Re: [cmake-developers] FindCUDA bug fixes

On 08/31/2016 10:50 AM, Sorley, Stephen L. wrote: > I’ve attached two patches that fix bugs Thanks, applied: FindCUDA: Fix for broken cuda_compile* commands. https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6442709b FindCUDA: Allow cuda_compile* macros to be called more than once per

Re: [cmake-developers] Android.mk

On 08/31/2016 11:47 AM, tim cotter wrote: > is anyone working on a generator for Android.mk files? This has been investigated in the past and deemed hard/impossible since the Android.mk build system does not expose hooks we need. However, the main use case for this is to bring CMake-based

[Cmake-commits] CMake branch, next, updated. v3.6.1-1663-g908cfab

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, next has been updated via 908cfab96a7cb0edbde586e6b31d28f36623577f (commit) via

[cmake-developers] FindCUDA bug fixes

I've attached two patches that fix bugs in the CUDA_COMPILE{,_PTX,_FATBIN,_CUBIN} macros from FindCUDA.cmake. First bug (fixed by patch #1) Commit 7ded655 added generator expressions in CUDA_WRAP_SRCS to scrape include directories and compile definitions off of the target. This works great

[Cmake-commits] CMake branch, next, updated. v3.6.1-1661-gc01d364

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, next has been updated via c01d364e2bd3ce04cc251e44aa21022204d69176 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.1-822-g901a060

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 901a06021e169bdfa19633370192870385868a7d (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.1-1659-g50ecee5

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, next has been updated via 50ecee5c02947588ad55575ec41d033e318087ba (commit) via

Re: [cmake-developers] [PATCH] install: correctly deal with paths in generator expressions in DIRECTORY

On 08/31/2016 03:41 AM, Yves Frederix wrote: > Please let me know what you decide Thanks. I decided to apply the patch as-is with minor tweaks: install: Fix evaluation of leading generator expressions in DIRECTORY https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3bd55dba -Brad --

Re: [CMake] CMake library installations and pkg-config

31.08.2016, 16:22, "Nick Appleton" : > Hi, > > I’ve been recently doing a bit of work for an open source project trying to > extend it’s support for CMake. I’ve been trying to get CMake to be able to > replicate most of the functionality which can be achieved with the

[Cmake-commits] CMake branch, next, updated. v3.6.1-1657-g7cb415e

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, next has been updated via 7cb415ef8b47a1f0ac6a40c2e7e2a6885a30c78d (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.1-818-ga9affa0

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 a9affa07cdeea6b66c920e4826abfe59854f7ffa (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.1-790-g59d559a

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 59d559af2e35d3521c7cffc4a0c7c33ffaf2c744 (commit) via

[CMake] CMake library installations and pkg-config

Hi, I’ve been recently doing a bit of work for an open source project trying to extend it’s support for CMake. I’ve been trying to get CMake to be able to replicate most of the functionality which can be achieved with the existing autoconf-based infrastructure (and have had pretty good

[Cmake-commits] CMake branch, master, updated. v3.6.1-810-g6f8b939

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 6f8b93983a3bfb4a9262cae8e9b989edb61e8a4b (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.1-820-g0a2d0b1

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 0a2d0b126ca01a7d989a887c71693989e9d15224 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.1-814-g0820c78

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 0820c7850805e7c41fd54292fa4ebd13b28b51fa (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.1-812-g5b1f9cd

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 5b1f9cd12703eca0505ee0b6d9d2a0e53ed86f67 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.1-1647-g698e662

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, next has been updated via 698e66225604dfd7b2419d2459bddcbc08c609b9 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.1-1625-g755bc1d

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, next has been updated via 755bc1d12bcfe2c4cac7fc488810d7064f774acf (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.1-1623-gf631705

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, next has been updated via f631705425da0a343b6c27de77be88fcacff34e6 (commit) via

[CMake] User-overriding IMPORTED targets (overlaying libraries, ...)

Hello, Let's suppose I have a project Foo which generates a shared library `libfoo.so`, and a project Bar which links to `foo` and builds an executable `bar`. Let's also suppose that as a maintainer, I wrote a library `libfoo_overlay.so` which links to `libfoo.so` and redefines certain symbols

Re: [cmake-developers] [PATCH] install: correctly deal with paths in generator expressions in DIRECTORY

Hi Brad, >> +if (!cmSystemTools::FileIsFullPath(i->c_str())) { >> + *i = std::string(makefile.GetCurrentSourceDirectory()) + "/" + *i; > > Perhaps we should issue a diagnostic here. In principle the caller > should always provide a full path. If they use a genex to do it then > they