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

2016-05-10 Thread Taylor Braun-Jones 
This is a minor usability improvement that allows easily setting the
indentation width for cmake-mode (and making the variable buffer-specific
using make-local-variable). Useful when working with CMake code from code
bases that use different indentation standards.

Taylor
From 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 deletion(-)

diff --git a/Auxiliary/cmake-mode.el b/Auxiliary/cmake-mode.el
index d74dba0..20def8b 100644
--- a/Auxiliary/cmake-mode.el
+++ b/Auxiliary/cmake-mode.el
@@ -228,7 +228,9 @@ the indentation.  Otherwise it retains the same position on the line"
 ;;
 ;; Indentation increment.
 ;;
-(defvar cmake-tab-width 2)
+(defcustom cmake-tab-width 2
+  "Number of columns to indent cmake blocks"
+  :type 'integer)
 
 ;--
 
-- 
2.7.4

-- 

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-developers

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

2016-03-22 Thread Taylor Braun-Jones 
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 using the ZERO_CHECK target because
>> it does not exist in all VS generators.  I had added custom target
>> to the test case to use instead.
>
> Done - see attached.

Whoops - I didn't update unit test in patch 0002 properly. Here's a
new patch that's not broken.
From 56455ff8caecb1357737b1af533046bda083e382 Mon Sep 17 00:00:00 2001
From: Taylor Braun-Jones <tay...@braun-jones.org>
Date: Mon, 21 Mar 2016 16:01:20 -0400
Subject: [PATCH 2/3] VS: Fix default target support for targets nested inside
 a folder

---
 Source/cmGlobalVisualStudio71Generator.cxx | 5 -
 Tests/RunCMake/VSSolution/RunCMakeTest.cmake   | 1 +
 Tests/RunCMake/VSSolution/StartupProjectUseFolders-check.cmake | 9 +
 Tests/RunCMake/VSSolution/StartupProjectUseFolders.cmake   | 3 +++
 4 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 Tests/RunCMake/VSSolution/StartupProjectUseFolders-check.cmake
 create mode 100644 Tests/RunCMake/VSSolution/StartupProjectUseFolders.cmake

diff --git a/Source/cmGlobalVisualStudio71Generator.cxx b/Source/cmGlobalVisualStudio71Generator.cxx
index f6796a5..289fbb5 100644
--- a/Source/cmGlobalVisualStudio71Generator.cxx
+++ b/Source/cmGlobalVisualStudio71Generator.cxx
@@ -97,7 +97,8 @@ void cmGlobalVisualStudio71Generator
   OrderedTargetDependSet orderedProjectTargets(
 projectTargets, this->GetStartupProjectName(root));
 
-  this->WriteTargetsToSolution(fout, root, orderedProjectTargets);
+  std::stringstream targetsSlnString;
+  this->WriteTargetsToSolution(targetsSlnString, root, orderedProjectTargets);
 
   bool useFolderProperty = this->UseFolderProperty();
   if (useFolderProperty)
@@ -105,6 +106,8 @@ void cmGlobalVisualStudio71Generator
 this->WriteFolders(fout);
 }
 
+  fout << targetsSlnString.str();
+
   // Write out the configurations information for the solution
   fout << "Global\n";
   // Write out the configurations for the solution
diff --git a/Tests/RunCMake/VSSolution/RunCMakeTest.cmake b/Tests/RunCMake/VSSolution/RunCMakeTest.cmake
index 8ae9598..19b309c 100644
--- a/Tests/RunCMake/VSSolution/RunCMakeTest.cmake
+++ b/Tests/RunCMake/VSSolution/RunCMakeTest.cmake
@@ -10,3 +10,4 @@ run_cmake(Override1)
 run_cmake(Override2)
 run_cmake(StartupProject)
 run_cmake(StartupProjectMissing)
+run_cmake(StartupProjectUseFolders)
diff --git a/Tests/RunCMake/VSSolution/StartupProjectUseFolders-check.cmake b/Tests/RunCMake/VSSolution/StartupProjectUseFolders-check.cmake
new file mode 100644
index 000..c0a545a
--- /dev/null
+++ b/Tests/RunCMake/VSSolution/StartupProjectUseFolders-check.cmake
@@ -0,0 +1,9 @@
+getProjectNames(projects)
+list(GET projects 0 first_project)
+if(NOT first_project STREQUAL "CMakePredefinedTargets")
+  error("CMakePredefinedTargets is not the first project")
+endif()
+list(GET projects 1 second_project)
+if(NOT second_project STREQUAL "TestStartup")
+  error("TestStartup does not immediately follow the CMakePredefinedTargets project")
+endif()
diff --git a/Tests/RunCMake/VSSolution/StartupProjectUseFolders.cmake b/Tests/RunCMake/VSSolution/StartupProjectUseFolders.cmake
new file mode 100644
index 000..8e422a4
--- /dev/null
+++ b/Tests/RunCMake/VSSolution/StartupProjectUseFolders.cmake
@@ -0,0 +1,3 @@
+add_custom_target(TestStartup)
+set_property(GLOBAL PROPERTY USE_FOLDERS ON)
+set_property(DIRECTORY PROPERTY VS_STARTUP_PROJECT "TestStartup")
-- 
2.7.2.windows.1

-- 

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-developers

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

2016-03-21 Thread Taylor Braun-Jones 
On Fri, Mar 18, 2016 at 1:31 PM, Brad King <brad.k...@kitware.com> wrote:
>
> Please check that the revised version works for you.

I did some more thorough testing and ran into an issue when
USE_FOLDERS is enabled. The problem is actually the same one affecting
the ALL_BUILD target that is preventing it from being grouped with the
PREDEFINED_TARGETS_FOLDER as it should be. It's not actually the first
target in a .sln file that is treated as the default startup project,
but rather the first _fully defined target_. See this SO comment
thread:

http://stackoverflow.com/questions/694730/why-is-set-as-startup-option-stored-in-the-suo-file-and-not-the-sln-file#comment40597475_1808352

The solution is to just list all folders in the .sln file first (patch
0002). With the fix in patch 0002, ALL_BUILD can then be put in
PREDEFINED_TARGETS_FOLDER (patch 0003).

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 more flexible version
`getProjectNames`
---
 Tests/RunCMake/VSSolution/StartupProject-check.cmake  |  3 ++-
 .../RunCMake/VSSolution/StartupProjectMissing-check.cmake |  3 ++-
 Tests/RunCMake/VSSolution/solution_parsing.cmake  | 15 ---
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/Tests/RunCMake/VSSolution/StartupProject-check.cmake b/Tests/RunCMake/VSSolution/StartupProject-check.cmake
index fd7cc28..8890334 100644
--- a/Tests/RunCMake/VSSolution/StartupProject-check.cmake
+++ b/Tests/RunCMake/VSSolution/StartupProject-check.cmake
@@ -1,4 +1,5 @@
-getFirstProject(first_project StartupProject)
+getProjectNames(projects)
+list(GET projects 0 first_project)
 if(NOT first_project STREQUAL "ZERO_CHECK")
   error("ZERO_CHECK is not the startup project")
 endif()
diff --git a/Tests/RunCMake/VSSolution/StartupProjectMissing-check.cmake b/Tests/RunCMake/VSSolution/StartupProjectMissing-check.cmake
index 95fede7..b1017dd 100644
--- a/Tests/RunCMake/VSSolution/StartupProjectMissing-check.cmake
+++ b/Tests/RunCMake/VSSolution/StartupProjectMissing-check.cmake
@@ -1,4 +1,5 @@
-getFirstProject(first_project StartupProjectMissing)
+getProjectNames(projects)
+list(GET projects 0 first_project)
 if(NOT first_project STREQUAL "ALL_BUILD")
   error("ALL_BUILD is not the startup project")
 endif()
diff --git a/Tests/RunCMake/VSSolution/solution_parsing.cmake b/Tests/RunCMake/VSSolution/solution_parsing.cmake
index 001b584..4e5bb59 100644
--- a/Tests/RunCMake/VSSolution/solution_parsing.cmake
+++ b/Tests/RunCMake/VSSolution/solution_parsing.cmake
@@ -50,17 +50,18 @@ macro(parseGlobalSections arg_out_pre arg_out_post testName)
 endmacro()
 
 
-macro(getFirstProject arg_out_first_project testName)
-  set(${arg_out_first_project} "")
-  set(sln "${RunCMake_TEST_BINARY_DIR}/${testName}.sln")
+macro(getProjectNames arg_out_projects)
+  set(${arg_out_projects} "")
+  set(sln "${RunCMake_TEST_BINARY_DIR}/${test}.sln")
   if(NOT EXISTS "${sln}")
 error("Expected solution file ${sln} does not exist")
   endif()
   file(STRINGS "${sln}" project_lines REGEX "^Project\\(")
-  list(GET project_lines 0 first_project)
-  string(REGEX REPLACE ".* = \"" "" first_project "${first_project}")
-  string(REGEX REPLACE "\", .*"  "" first_project "${first_project}")
-  set(${arg_out_first_project} "${first_project}")
+  foreach(project_line IN LISTS project_lines)
+string(REGEX REPLACE ".* = \"" "" project_line "${project_line}")
+    string(REGEX REPLACE "\", .*"  "" project_line "${project_line}")
+list(APPEND ${arg_out_projects} "${project_line}")
+  endforeach()
 endmacro()
 
 
-- 
2.7.2.windows.1

From 898826c3dfb86078c6b42578d4bb5ae991552ecc Mon Sep 17 00:00:00 2001
From: Taylor Braun-Jones <taylor.braunjo...@avigilon.com>
Date: Mon, 21 Mar 2016 16:01:20 -0400
Subject: [PATCH 2/3] VS: Fix default target support for targets nested inside
 a folder

---
 Source/cmGlobalVisualStudio71Generator.cxx | 5 -
 Tests/RunCMake/VSSolution/RunCMakeTest.cmake   | 1 +
 Tests/RunCMake/VSSolution/StartupProjectUseFolders-check.cmake | 9 +
 Tests/RunCMake/VSSolution/StartupProjectUseFolders.cmake   | 2 ++
 4 files changed, 16 insertions(+), 1 deletion(-)
 create mode 100644 Tests/RunCMake/VSSolution/StartupProjectUseFolders-check.cmake
 create mode 100644 Tests/RunCMake/VSSolution/StartupProjectUseFolders.cmake

diff --git a/Source/cmGlobalVisualStudio71Generator.cxx b/Source/cmGlobalVisualStu

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

2016-03-19 Thread Taylor Braun-Jones 
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  wrote:
> On 06/16/2015 07:34 PM, Davy Durham wrote:
>> Would that involve different macro's anyhow?  I could try
>> and write a macro specifically to check that, or were you thinking I
>> should be able to use the macros that are already there?  And would you
>> be opposed to my writing a dedicated one?
>
> Please write your own if needed.  I was just pointing out that the
> test already does something similar to what you need.
>
> Thanks,
> -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-developers


0001-Add-VS_STARTUP_PROJECT-directory-property-15578.patch
Description: Binary data


0002-fixup-Add-VS_STARTUP_PROJECT-directory-property-1557.patch
Description: Binary data


0003-fixup-Add-VS_STARTUP_PROJECT-directory-property-1557.patch
Description: Binary data


0004-fixup-Add-VS_STARTUP_PROJECT-directory-property-1557.patch
Description: Binary data
-- 

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-developers

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

2016-03-15 Thread Taylor Braun-Jones 
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 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-developers

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

2016-03-14 Thread Taylor Braun-Jones 
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 USE_FOLDERS ON)

Targets like ZERO_CHECK, INSTALL, and RUN_TESTS work for me; just not ALL_BUILD.

Thanks,
Taylor
-- 

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-developers

Re: [cmake-developers] CMake Daemon blog

2016-02-16 Thread Taylor Braun-Jones 
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

Thanks for sharing, Stephen! Do you plan to also share the standalone
Qt-based editor/client as well (cmake-browser)? That would be
immediately useful to me and allow me to more easily test drive all
this work that you've done.

Cheers,
Taylor
-- 

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-developers

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

2016-02-11 Thread Taylor Braun-Jones 
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 it?

Thanks,
Taylor

[1] https://cmake.org/Bug/view.php?id=15954
-- 

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-developers

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

2016-01-28 Thread Taylor Braun-Jones 
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-based systems)
>
> Should I expect to see the -l3 option to be propagated automatically to
the sub projects of my superbuild? Or do I need to do some special cmake
configuration to make this happen? Or is this just a known issue?

I'm still seeing this behavior with CMake 3.4.1. Here's a friendlier
plaintext representation of the previous htop screenshot snippet:

ninja -l3
└── /usr/bin/ninja-build
├── /usr/bin/ninja-build
└── /usr/bin/ninja-build

Is this expected behavior, a known bug, or a new bug that I should file?
Note that this example shows the -l option not being propagated, but I
think all of the following Ninja options should be propagated:

  -l N do not start new jobs if the load average is greater than N
  -n   dry run (don't run commands but act like they succeeded)
  -v   show all command lines while building
  -d stats print operation counts/timing info
  -d explain   explain what caused a command to execute
  -t clean clean built files
  -t commands  list all commands required to rebuild given targets

Thanks,
Taylor
-- 

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-developers

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

2016-01-28 Thread Taylor Braun-Jones 
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 should be.
>> Should CMake be using the subninja[1] keyword to include the
>> build.ninja of External Projects?
>
> That would be possible with the work that's been done here:
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15364

Awesome. Nothing left to be said in this thread. I'll start following that one.

Taylor
-- 

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-developers

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

2016-01-28 Thread Taylor Braun-Jones 
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 should be.
Should CMake be using the subninja[1] keyword to include the
build.ninja of External Projects?

[1] https://ninja-build.org/manual.html#ref_scope
-- 

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-developers

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

2016-01-19 Thread Taylor Braun-Jones 
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 exact same version of Bar that Foo was originally built with
>
> COMPATIBLE_INTERFACE_STRING and similar properties are designed for that use
> case.
>
> You would populate an INTERFACE_ property on the INTERFACE target, which is
> whitelisted already:
>
>  
> https://cmake.org/cmake/help/v3.4/manual/cmake-buildsystem.7.html#compatible-interface-properties
>
>  http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/5813

Thanks - that's exactly what I was looking for!

Taylor
-- 

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-developers

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

2016-01-19 Thread Taylor Braun-Jones 
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:
>>
>> https://github.com/Kitware/CMake/compare/master...nocnokneo:patch-1
>>
>> Otherwise, the test step gives the error "Test not available without
>> configuration."
>
> Good catch.  Please try these changes:
>
>  ExternalProject: Simplify `cmake --build` configuration passing
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b95be1cf
>
>  ExternalProject: Fix TEST_BEFORE_INSTALL for multi-config generators
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f565f9fa

Thanks - works!

However, these patches use the deprecated $ generator
expression instead of $. The rest of ExternalProject.cmake
uses $.

Taylor
-- 

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-developers

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

2016-01-19 Thread Taylor Braun-Jones 
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,
Taylor
-- 

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-developers

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

2016-01-11 Thread Taylor Braun-Jones 
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 during setting only, wouldn't this be
>> sufficient? This would make it possible to simply access all
>> properties that are automatically assigned to the target (which I
>> assume implies that by definition they should make sense?). A
>> non-acceptable property could not have been set and would hence not be
>> found, making it possible to check for its existence in the "standard"
>> way.
>>
>
> The same argument might hold for getting of properties.
> E.g. hypothetically if SOURCE_DIR were not set for INTERFACE properties
> now but was implemented in the future.
>
> A user might e.g. think that a specific property should work because CMake
>>> did not issue any diagnostics and open an issue.
>>> The diagnostic implies that this behavior is by design.
>>>
>>> It also prevents users from using existing properties which currently
>>> don't
>>> have semantics for INTERFACE targets but might be implemented in the
>>> future
>>> (potentially with different semantics than expected by the user).
>>>
>> Ok, this somehow contradicts my above assumption and is somewhat
>> surprising. Wouldn't it make sense to simply not set these properties
>> in the first place if they have incorrect semantics? This way,
>> get_property would not need to care about them and it would anyhow not
>> stop their correct implementation in the future.
>>
>
> I meant existing as in defined for regular build targets not as in
> actually set for interface targets.
> get_property() would return an empty string for those if they weren't
> whitelisted and one might argue that this could suffice.
> On the other hand users often assume that they get a valid value and don't
> actually check.
>
>
>>> I think allowing custom (non cmake defined) properties might be a valid
>>> argument.
>>> These could perhaps also be supported through e.g. user extension of the
>>> whitelist.
>>>
>> I like this idea. With this in place, one would not need to wait for a
>> new CMake release if a valid property were missing from the whitelist
>> or if one wanted to use custom properties.
>>
>> I don't think anything should be changed however unless there are actual
>>> use
>>> cases that aren't supported by the current implementation.
>>>
>> Does this mean that you would have doubts about patches that:
>>   - provide a way for the user to extend the whitelist?
>>   - remove the need for whitelisting in get_property by making CMake
>> only automatically assign sensible target properties?
>>
>
> The issue is less that CMake assigns these properties (I don't know of any
> such case but I haven't checked) and more that users might just expect them
> to be set (which does not provide a diagnostic).
>
> Personally I would not object to either approach as long as there are
> actual use cases.
> Without use cases such changes would be by definition useless.


I have another INTERFACE property use case that is not whitelisted, but
should be: VERSION

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 exact same version of Bar that Foo was originally built with
(Failure to do so can lead to subtle, hard-to-find bugs like violation of
the one definition rule). Assuming project Bar creates an imported target
"Bar" with a VERSION property set like:

  set_property(TARGET Bar APPEND PROPERTY VERSION 1.2.3)

Then project Foo should be able to have something like:

== CMakeLists.txt ==
...
get_property(FOO_BAR_VERSION TARGET BAR PROPERTY VERSION)
configure_file(FooConfig.cmake.in FooConfig.cmake @ONLY)

== FooConfig.cmake.in ==
...
find_package(Bar "@FOO_BAR_VERSION@" EXACT REQUIRED)

But, alas, this is not currently possible. I'm ambivalent about whether
INTERFACE properties should be whitelisted vs blacklisted vs unrestricted,
but at least this VERSION property seems valid to allow.

Taylor
-- 

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-developers

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

2015-12-03 Thread Taylor Braun-Jones 
Perhaps the Paris Climate talks would be good inspiration for tackling
this feature. How many pounds of CO2 are emitted each year due to
needless header compilation CPU cycles? :-)

On Fri, Oct 30, 2015 at 1:48 AM, James Johnston
<johnstonj.pub...@codenest.com> wrote:
>> -Original 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-developers] RFC: CMake precompiled header support
>
>> and custom compiler based implementation
>
>>
>
>> On Tue, Oct 27, 2015 at 3:53 AM, Taylor Braun-Jones <taylor@braun-
>
>> jones.org> wrote:
>
>> > What's the status of this PCH feature? Does it need testers? More
>
>> > design input? I'd love to see this feature in a future CMake release.
>
>> > Willing to help.
>
>>
>
>> I haven't worked on it for quite some time as I currently don't have a
>
> project
>
>> which needs it.
>
>> But I agree that we should get it into CMake, even if it does not
>
>> support
>
> all
>
>> generators yet.
>
>> Support for additional generators can be added successively.
>
>>
>
>> 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.
>
>>
>
>> Which generators are the most important for you?
>
>
>
> I'd also love to see some progress on PCH support, though I haven't had much
> time recently... I'd be quite happy to test however with the below compilers
> and generators - all of which we would use PCH support with:
>
>
>
> Generators:
>
>
>
> * Ninja
>
> * Visual Studio 2008 (eventually 2015)
>
> * Although we're not currently using it, CMake would be pretty broken
> without supporting: Unix Makefiles
>
>
>
> Compilers:
>
>
>
> * Visual C++ 2008 (eventually 2015): both Ninja and VS generators
>
> * Embarcadero bcc32 compiler: Ninja
>
> * GCC: Ninja
>
>
>
> Best regards,
>
>
>
> James Johnston
>
>
> --
>
> 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-developers
-- 

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-developers

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

2015-10-28 Thread Taylor Braun-Jones 
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 the most important for you?
>

For me, generators in order of most important to least are:

Ninja
Unix Makefiles
Visual Studio 12 2013

- Taylor
-- 

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-developers

[cmake-developers] CMake strips MAKEFLAGS from environment

2015-05-21 Thread Taylor Braun-Jones 
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 working C compiler: /usr/lib64/ccache/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/lib64/ccache/c++
-- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
MAKEFLAGS:
FOO: bar
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/test_env_makeflags

Why is CMake stripping MAKEFLAGS from its environment? I couldn't find any
documentation describing this as normal/expected behavior.

Thanks,
Taylor
-- 

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-developers

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

2015-05-21 Thread Taylor Braun-Jones 
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 environment.


Ya, that was one of my first thoughts and it does make things simpler. But
I wanted developers to be able to get instant coverage feedback at their
desktop to shorten the write test/check coverage cycle. We have high MC/DC
coverage goals and as you start to approach 100% coverage it's not always
obvious what conditions/decisions are the missing coverage. I also want to
keep the usage simple and consistent meaning that code coverage and static
analysis reports should be available as a build target (e.g. `make
coverage_report coverity_report`)

Taylor
-- 

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-developers

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

2015-05-21 Thread Taylor Braun-Jones 
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 it so that it has a better expectation of how things will run. Is
 there a reason you can't use a CMake cache variable to set
 `environment_build_flags` rather than the environment (since it would
 get remembered between cmake runs while the environment needs to be
 specified every time)?


Ya, I could definitely use a cache variable and that probably makes sense
to do here. But I'm not sure how it solves my problem. For example, with
this CMakeLists.txt:

cmake_minimum_required(VERSION 3.0)
set(environment_build_flags $ENV{MAKEFLAGS} CACHE STRING MAKEFLAGS)
add_custom_target(echo_makeflags COMMAND echo environment_build_flags:
${environment_build_flags} VERBATIM)

I still just get:

$ make echo_makeflags
environment_build_flags:
Built target echo_makeflags

Taylor
-- 

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-developers

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

2015-05-21 Thread Taylor Braun-Jones 
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 COVFILE=${PROJECT_BINARY_DIR}/bullseye/test.cov)
  add_custom_target(coverage_data
COMMAND env ${bullseye_environment}
  ${CMAKE_COMMAND} --build ${PROJECT_BINARY_DIR} --clean-first
COMMAND env ${bullseye_environment} ${CMAKE_CTEST_COMMAND}
--output-on-failure
COMMENT Generating test coverage data
VERBATIM
)

Which works fine for Ninja generator. It works for Unix Makefiles too,
except that the parallelism is lost. I get errors like:

gmake[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.

So I added another workound for that:

  if(${CMAKE_GENERATOR} MATCHES .* Makefiles$)
set(environment_build_flags $ENV{MAKEFLAGS})
  endif()

  add_custom_target(coverage_data
COMMAND env --unset=MAKEFLAGS ${bullseye_environment}
  ${CMAKE_COMMAND} --build ${PROJECT_BINARY_DIR} --clean-first --
${environment_build_flags}
COMMAND env ${bullseye_environment} ${CMAKE_CTEST_COMMAND}
--output-on-failure
COMMENT Generating test coverage data
VERBATIM
)

Which allows the parallelism to work properly in an environment like:

export MAKEFLAGS=$(grep -i -c ^processor /proc/cpuinfo)
make coverage_data

Taylor
-- 

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-developers

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

2015-05-21 Thread Taylor Braun-Jones 
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 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-developers

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

2015-05-18 Thread Taylor Braun-Jones 
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 because ctest directly runs the tests.
 There is no way to implement environment settings consistently
 across all generators when launching compiler tools.  The VS
 and Xcode IDE project files provide no way to do it in general.
 Our workflow for command-line builds has always been to have the
 necessary environment variables defined by the caller and not
 within the scope of CMake.


Okay, I had a hunch this might be the case. Thanks for clarifying.

Taylor
-- 

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-developers

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

2015-05-16 Thread Taylor Braun-Jones 
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) One of the values contains the path to the build dir so now I'd need to
_generate_ the interceptor script that I want to use as my
CMAKE_CXX_COMPILER.

(2) I also want the environment variables to be visible to the executables
that get invoked when building various other targets. Since the paths to
these executables get discovered by CMake (they are not necessarily in the
system PATH) I'd be stuck generating several wrapper/interceptor scripts.

These issues could likely be overcome with workarounds, but I'm trying hard
to keep the build simple and understandable. Since CMake already has an
ENVIRONMENT property for tests[1] it seemed like a reasonable and symmetric
feature would be to support an ENVIRONMENT property for targets as well.

Taylor

[1]
http://www.cmake.org/cmake/help/v3.2/manual/cmake-properties.7.html#properties-on-tests
-- 

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-developers

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

2014-09-22 Thread Taylor Braun-Jones 
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 place of the current call
 to _ExternalData_download_file with the part of the URL after
 the MyFetch/ already parsed into some variable(s).


This all sounds reasonable to me. I'd love to see this land in a future
CMake release. I'm willing to help if you need a tester/reviewer.
-- 

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-developers

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

2014-09-19 Thread Taylor Braun-Jones 
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 be activated by a special format of an entry in
 ExternalData_URL_TEMPLATES that specifies a lookup key that maps
 to some kind of custom configuration of a .cmake script to include
 or command to launch with execute_process.


How about defining new URL scheme like:

externaldatacommand://*file|module*/*command*

Where *file|module* is something that can be passed to the include command
and defines a function or macro named *command*. *command* would then be
called like:

command(outputfile algo hash)

So, using Artifactory as an example case, a projects CMakeLists.txt might
look like:

list(APPEND CMAKE_MODULE_PATH
  ${CMAKE_SOURCE_DIR}/Testing/CMake
)
set(ARTIFACTORY_BASE_URL https://example.com/artifactory)
list(APPEND ExternalData_URL_TEMPLATES

externaldatacommand://ArtifactoryExternalData/ARTIFACTORY_DOWNLOAD_FILE?ALGO=%(algo)
)

And inside Testing/CMake/ArtifactoryExternalData.cmake it would look like:

function(ARTIFACTORY_DOWNLOAD_FILE file algo hash)
  set(json_response_file
${CMAKE_BINARY_DIR}/artifactory_search_${algo}_${hash}.json)
  set(artifact_search_query
${ARTIFACTORY_BASE_URL}/api/search/checksum?${algo}=${hash})

  message(Query URI: ${artifact_search_query})

  file(DOWNLOAD ${artifact_search_query} ${json_response_file} STATUS
status)
  list(GET status 0 error_code)
  list(GET status 1 error_message)
 if(error_code)
   file(REMOVE ${json_response_file})
   message(FATAL_ERROR Artifactory query failed with error ${error_code}:
${error_message})
 endif()

  # For testing
  file(WRITE ${json_response_file} {\results\:[{\uri\:\
https://example.com/artifactory/api/storage/repo1-cache/lena.png\}]};)

  file(READ ${json_response_file} json_response)
  file(REMOVE ${json_response_file})

  # Normalize the JSON response by removing any whitespace (makes it easier
to parse)
  string(REGEX REPLACE [ \t\n\r]+  json_response ${json_response})

  if(NOT json_response MATCHES \uri\:)
message(FATAL_ERROR Artifactory file was not found)
  endif()

  string(REGEX MATCH https?://[^\]+ artifact_uri ${json_response})
  message(Artifact URI: ${artifact_uri})

  file(DOWNLOAD ${artifact_uri} ${file} STATUS status)
  list(GET status 0 error_code)
  list(GET status 1 error_message)
  if(error_code)
message(FATAL_ERROR Artifactory download failed with error
${error_code}: ${error_message})
  endif()
endfunction()

Then if you had:

ExternalData_Add_Test(MyProjectData
  NAME SmoothingTest
  COMMAND SmoothingExe DATA{Input/Image.png}
   SmoothedImage.png
  )

The ExternalData framework would execute:

ARTIFACTORY_DOWNLOAD_FILE(${ExternalData_BINARY_ROOT}/Input/Image.png md5
1234567890abcdef1234567890abcdef)

Thoughts?

Taylor
-- 

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-developers