Re: [cmake-developers] [CMake] Integrating ExternalData with Artifactory

Shifting discussion to cmake-developers. On Fri, Sep 19, 2014 at 3:04 PM, Brad King brad.k...@kitware.com wrote: On 09/19/2014 12:23 PM, Taylor Braun-Jones wrote: integrate Artifactory with the ExternalData framework? the Artifactory REST API is a two step process I think it can

Re: [cmake-developers] [CMake] Integrating ExternalData with Artifactory

On Mon, Sep 22, 2014 at 10:07 AM, Brad King brad.k...@kitware.com wrote: Perhaps: list(APPEND ExternalData_URL_TEMPLATES ExternalDataCustomScript://MyFetch/%(algo)/%(hash) ) set(ExternalData_CUSTOM_SCRIPT_MyFetch /path/to/MyFetch.cmake) The script would be include()-ed in

Re: [cmake-developers] [CMake] Export environment variables in generated Makefile

On May 16, 2015 12:18 PM, Dan Kegel d...@kegel.com wrote: Write a wrapper script that sets the variables and invokes the compiler, and tell cmake that's your compiler. Ya, I thought about this but aside from having an interceptor for an interceptor there are also other complexities like: (1)

Re: [cmake-developers] [CMake] Export environment variables in generated Makefile

On Mon, May 18, 2015 at 8:48 AM, Brad King brad.k...@kitware.com wrote: On 05/17/2015 12:35 AM, Taylor Braun-Jones wrote: CMake already has an ENVIRONMENT property for tests ... symmetric feature would be to support an ENVIRONMENT property for targets as well. We can provide it for tests

[cmake-developers] CMake strips MAKEFLAGS from environment

This is what I'm seeing: $ echo 'message(MAKEFLAGS: $ENV{MAKEFLAGS}\nFOO: $ENV{FOO})' CMakeLists.txt $ MAKEFLAGS=test FOO=bar cmake . -- The C compiler identification is GNU 4.8.3 -- The CXX compiler identification is GNU 4.8.3 -- Check for working C compiler: /usr/lib64/ccache/cc -- Check for

Re: [cmake-developers] Running coverage tool with environment (was: CMake strips MAKEFLAGS from environment)

On Thu, May 21, 2015 at 10:19 AM, Brad King brad.k...@kitware.com wrote: We typically run coverage as part of nightly testing with a 'ctest -S' dashboard client script. The script surrounds the actual build invocation and can take responsibility for adding things like COVFILE to the

Re: [cmake-developers] CMake strips MAKEFLAGS from environment

On Thu, May 21, 2015 at 9:44 AM, Ben Boeckel ben.boec...@kitware.com wrote: The problem with MAKEFLAGS is that `-i` also gets inherited and that is not acceptable to use when running things like try_compile since it causes false positives (e.g., detecting NEON extensions on x86). CMake clears

Re: [cmake-developers] CMake strips MAKEFLAGS from environment

On Thu, May 21, 2015 at 8:56 AM, Brad King brad.k...@kitware.com wrote: What are you trying to do? I'm trying to implement a workaround solution for setting environment variables in my Makefiles at build time. So what I started with was this: set(bullseye_environment

Re: [cmake-developers] CMake strips MAKEFLAGS from environment

On Thu, May 21, 2015 at 10:14 AM, Brad King brad.k...@kitware.com wrote: You could try using +env as your COMMAND instead, though I wouldn't consider this an officially supported approach. Thanks - that works and is a much better workaround. -- Powered by www.kitware.com Please keep

Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

On Wed, Oct 28, 2015 at 4:57 AM, Daniel Pfeifer wrote: > I will rebase my branch to master on the weekend, ie port it to > cmGeneratorTarget. > Then you are free to help with review, testing, and additional generators. > Great! Just let me know. > Which generators are

Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

inal Message- > >> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > >> On Behalf Of Daniel Pfeifer > >> Sent: Wednesday, October 28, 2015 08:57 > >> To: Taylor Braun-Jones > >> Cc: CMake Developers > >> Subject: Re: [cmake

Re: [cmake-developers] [CMake] Why does INTERFACE type targets only support whitelisted properties?

On Fri, Jan 8, 2016 at 9:12 AM, Nils Gladitz wrote: > > > On 01/08/2016 02:50 PM, Yves Frederix wrote: > >> You are explicitly mentioning 'setting' of a property. IMHO there is a >> big difference between setting and getting a property. If >> white/blacklisting is enforced

[cmake-developers] 15954: Ninja generated superbuilds do not reinstall dependent projects

I'm curious about bug 15954[1]. I'm having the same issue and I'd expect that many others would be running to the issue too since the Ninja generator and the ExternalProjects module have become quite popular. Could I get confirmation that it's a real bug and a quick pointer on where to look to fix

Re: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects

On Sat, Mar 28, 2015 at 10:38 AM, Taylor Braun-Jones <tay...@braun-jones.org> wrote: > > See htop screenshot below for an example of what I mean. Note that `ninja` in the original command line invocation is just a bash alias for ninja-build (the name of the ninja binary on Fedora-b

Re: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects

On Thu, Jan 28, 2016 at 3:36 PM, Ben Boeckel <ben.boec...@kitware.com> wrote: > On Thu, Jan 28, 2016 at 15:15:58 -0500, Taylor Braun-Jones wrote: >> That's too bad. I understand the perspective of the Ninja developers, >> but it's not clear to me what the proposed alternative

Re: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects

On Thu, Jan 28, 2016 at 11:28 AM, Nicolas Desprès wrote: > Unfortunately, Ninja won't offer it: > https://github.com/ninja-build/ninja/pull/1079 That's too bad. I understand the perspective of the Ninja developers, but it's not clear to me what the proposed alternative

Re: [cmake-developers] [CMake] Why does INTERFACE type targets only support whitelisted properties?

On Mon, Jan 11, 2016 at 5:16 PM, Stephen Kelly <steveire@gmaicom> wrote: > Taylor Braun-Jones wrote: > >> Consider library project Foo that uses a header-only project Bar. In >> FooConfig.cmake, it is a important to ensure any projects using Foo also >> use the exac

Re: [cmake-developers] BUG: Pass --build-config option to ctest for multi-config ExternalProjects

On Tue, Jan 19, 2016 at 4:18 PM, Brad King <brad.k...@kitware.com> wrote: > On 01/19/2016 03:54 PM, Taylor Braun-Jones wrote: >> For ExternalProjects built with a multi-config generator like "Visual >> Studio 12" with `TEST_BEFORE_INSTALL ON` I need this patch: &

[cmake-developers] BUG: Pass --build-config option to ctest for multi-config ExternalProjects

For ExternalProjects built with a multi-config generator like "Visual Studio 12" with `TEST_BEFORE_INSTALL ON` I need this patch: https://github.com/Kitware/CMake/compare/master...nocnokneo:patch-1 Otherwise, the test step gives the error "Test not available without configuration." Thanks,

Re: [cmake-developers] CMake Daemon blog

On Sat, Jan 30, 2016 at 2:06 AM, Stephen Kelly wrote: > I've just pushed the daemon code here: > > https://github.com/steveire/cmake/tree/cmake-daemon > > The Kate plugin should soon appear here I think: > > https://quickgit.kde.org/?p=scratch%2Fskelly%2Fcmakekate.git

Re: [cmake-developers] BUG: ALL_BUILD not added to the PREDEFINED_TARGETS_FOLDER

On Tue, Mar 15, 2016 at 4:28 AM, Nils Gladitz wrote: > > https://cmake.org/Bug/view.php?id=15578 > https://cmake.org/Bug/view.php?id=15931 It seems like one of those reports should be marked as a duplicate of the other, no? -- Powered by www.kitware.com Please

[cmake-developers] BUG: ALL_BUILD not added to the PREDEFINED_TARGETS_FOLDER

For the Visual Studio generator, the ALL_BUILD is not added to the PREDEFINED_TARGETS_FOLDER ("CMakePredefinedTargets"). Tested on Windows 10 with Visual Studio 2013 using the following minimal CMakeLists.txt: cmake_minimum_required(VERSION 3.5) project(foobar) set_property(GLOBAL PROPERTY

Re: [cmake-developers] Startup Project Configuration [mantis 15578]

Here's Davy's patch rebased against current master with a unit test added. Tested on Visual Studio 2013 only. Let me know if I screwed up the rebase. Some conflicts weren't totally obvious to me how to handle. Thanks, Taylor On Thu, Jun 18, 2015 at 9:10 AM, Brad King

Re: [cmake-developers] Startup Project Configuration [mantis 15578]

Taylor From 2e4adaba69cd61143c468dc50b9bc82a06d5e484 Mon Sep 17 00:00:00 2001 From: Taylor Braun-Jones <taylor.braunjo...@avigilon.com> Date: Mon, 21 Mar 2016 14:34:34 -0400 Subject: [PATCH 1/3] fixup! VS: Add option to choose the `.sln` startup project (#15578) Change `getFirstProject` macro to mor

Re: [cmake-developers] Startup Project Configuration [mantis 15578]

On Tue, Mar 22, 2016 at 12:15 PM, Taylor Braun-Jones <tay...@braun-jones.org> wrote: > On Tue, Mar 22, 2016 at 11:49 AM, Brad King <brad.k...@kitware.com> wrote: >> Please revise 0001 to apply cleanly on top of 78ec0461. >> >> Also please revise 0002 to avoid us

[cmake-developers] cmake-mode.el: Make cmake-tab-width a customizable variable

f460bdfa6a01cdb1cd76d61eadcd1bf85d8c84c3 Mon Sep 17 00:00:00 2001 From: Taylor Braun-Jones <tay...@braun-jones.org> Date: Tue, 10 May 2016 10:34:16 -0400 Subject: [PATCH] cmake-mode.el: Make cmake-tab-width a customizable variable --- Auxiliary/cmake-mode.el | 4 +++- 1 file changed, 3 insertions(+), 1 de