[cmake-developers] HP-UX Curses questions
Hi
I'm suspecting that this block in FindCurses
https://github.com/Kitware/CMake/blob/master/Modules/FindCurses.cmake#L182-L185
should go away, unless there is something I have missed.
if (NOT CURSES_TINFO_HAS_CBREAK)
find_library(CURSES_EXTRA_LIBRARY cur_colr HINTS ${_cursesLibDir})
find_library(CURSES_EXTRA_LIBRARY cur_colr )
endif()
AFAICT, the cur_colr package was introduced in HP-UX 10.00 and marked as
deprecated in 10.30 by X/OPEN curses (which replaced the even older HP
curses in 10.10).
In order to use cur_colr after 10.10 you should use the
/usr/include/curses_colr when compiling. Since FindCurses doesn't even
search that path I suggest either to take out the library block
completely, since the support for cur_colr has never been complete or
add support for the special include path and also a flag to set a
preference on which kind of curses you want on HP-UX.
There is no 64-bit version of cur_colr in 11.11PA and it will be gone
completely in 11.31PA
(http://h21007.www2.hp.com/portal/download/files/unprot/STK/HPUX_STK/impacts/i964.html)
so without this change (and the other small change to enable Xcurses for
cmake below) I can't compile ccmake on that platform right now.
Ådne Hovda
diff --git a/Modules/FindCurses.cmake b/Modules/FindCurses.cmake
index a21ca89..f94bd09 100644
--- a/Modules/FindCurses.cmake
+++ b/Modules/FindCurses.cmake
@@ -179,11 +179,6 @@ if(NOT DEFINED CURSES_HAVE_CURSES_H)
endif()
endif()
-if (NOT CURSES_TINFO_HAS_CBREAK)
- find_library(CURSES_EXTRA_LIBRARY cur_colr HINTS ${_cursesLibDir})
- find_library(CURSES_EXTRA_LIBRARY cur_colr )
-endif()
-
find_library(CURSES_FORM_LIBRARY form HINTS ${_cursesLibDir})
find_library(CURSES_FORM_LIBRARY form )
diff --git a/Source/CursesDialog/form/form.priv.h
b/Source/CursesDialog/form/form.priv.h
index 3691f2f..889c6e4 100644
--- a/Source/CursesDialog/form/form.priv.h
+++ b/Source/CursesDialog/form/form.priv.h
@@ -34,7 +34,7 @@
#include form.h
/* get around odd bug on aCC and itanium */
-#if defined(__hpux) defined(__ia64)
+#if defined(__hpux)
#define getmaxx __getmaxx
#define getmaxy __getmaxy
#endif
--
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] [PATCH v3 0/2] Add continue keyword
On 15/11/14 12:36, Gregor Jasny wrote: the current version now properly checks for proper nesting of the continue keyword. To detect new scope blocks like for example a function() I hoked into the Push/PopScope functions. I just noticed that return() handling is broken. I'm also working on a patch that checks for proper usage of break(). Thanks, Gregor -- 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] New command 'file(LOCK_DIRECTORY ...)'
On 11/15/2014 03:34 AM, Rolf Eike Beer wrote:
Ruslan Baratov wrote:
Done. Also I've found parse issue which is based on `sscanf` behaviour,
e.g. string '123xyz' will be successfully parsed as a integer (%d). Same
issue for example in file(STRINGS) command:
I use strtol()/strtoul() for this kind of this, which also has a less
worrisome interface.
Yes, please change to that so a proper error can be produced for the new
API when 123xyz is given as a timeout, for example.
The file(STRINGS) command could be fixed with a separate change. In
order to be compatible it should do something like %u%c and produce
a warning if %c matched anything.
On 11/14/2014 06:27 PM, Ruslan Baratov wrote:
On linux you can test timeout by:
cat script.cmake
file(LOCK ${CMAKE_CURRENT_LIST_DIR}/file-to-lock TIMEOUT 5)
execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 10)
cmake -P script.cmake # start one instance in background
cmake -P script.cmake # start second instance, expected lock failed
by timeout
CMake Error at script.cmake:1 (file):
file : error locking file
/.../file-to-lock (Timeout
reached).
Please look at adding a case to the test suite for this. An outer
process could take the lock and then execute_process a child that
tries to take the lock with a timeout. Then check that it fails
as expected.
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
Re: [cmake-developers] Cannot Find MFC on Visual Studio 2013
On 11/16/2014 04:12 AM, ゑ wrote: I tried to 'FIND_PACKAGE(MFC)' on VS2013(community), but MFC not found. VS2013 has no mfc120.dll but has mfc120u.dll, so I make a patch for FindMFC.cmake, This is not just the community edition but any VS 2013. The MBCS (non-unicode) versions of the MFC libraries are no longer installed by default but can be downloaded separately. This was fixed for the InstallRequiredSystemLibraries module here: InstallRequiredSystemLibraries: MBCS MFC is optional on VS 12 (#14903) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c0a6646d Thanks for looking into it for FindMFC. +-DCOMPILE_DEFINITIONS:STRING=-D_UNICODE This works for VS 2013, but it breaks on older VS versions that do not have a unicode MFC library available. Also, an application cannot simply start using the unicode MFC if the application itself is not built with _UNICODE. I think we actually need two separate checks for the two separate libraries. The FindMFC module should be taught to check for the libraries with a separate MFC_HAVE_MFC_UNICODE cache entry. The old check can be renamed to MFC_HAVE_MFC_MBCS (and MFC_HAVE_MFC set to a copy of that result for compatibility with applications that look for it). Then the only problem is how to set MFC_FOUND based on the two results. For this we could use the COMPONENTS mechanism of find_package. Then an application could do one of: find_package(MFC) # found if mbcs libs are found find_package(MFC COMPONENTS mbcs) # found if mbcs libs are found find_package(MFC COMPONENTS unicode) # found if unicode libs are found find_package(MFC COMPONENTS mbcs unicode) # found if both are found The find module can check the MFC_FIND_COMPONENTS variable to see which parts the application wants. 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
[cmake-developers] Explicit custom command BYPRODUCTS
Hi Folks, Picking up from this old thread: explicit custom command side-effects (was: Severe regression caused by #14972 fixes) http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11207/focus=11225 and this issue: Add explicit specification of custom command side effect outputs http://www.cmake.org/Bug/view.php?id=14963 On 10/08/2014 10:26 AM, Brad King wrote: Both add_custom_target and add_custom_command can run operations that produce side-effects. Both commands need a way to specify any side effects they produce. Perhaps a new option like GENERATES can be added for this. The GENERATES value(s) would be marked with the GENERATED property. For Ninja we would add extra outputs to the generated rule and ask Ninja to restat them to avoid the always-rebuild case. For other generators no additional build system content is needed. I chose the name BYPRODUCTS for the option and drafted support: Add an option for explicit BYPRODUCTS of custom commands (#14963) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e15a7075 ExternalProject: Add options to specify BYPRODUCTS (#14963) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=557aef0b This was in 'next' over the weekend and is clean on the dashboard. To those that encountered problems requiring this feature, please try it out to see if it works correctly for your use case. 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
Re: [cmake-developers] explicit custom command side-effects
On 10/08/2014 10:26 AM, Brad King wrote: Both add_custom_target and add_custom_command can run operations that produce side-effects. Both commands need a way to specify any side effects they produce. Perhaps a new option like GENERATES can be added for this. For reference in list archives, this thread is continued here: Explicit custom command BYPRODUCTS http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11648 -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
[cmake-developers] [PATCH v4 1/3] Add continue keyword (#14013)
Original draft by Doug Barbieri.
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
Help/command/continue.rst | 7 +++
Source/cmBootstrapCommands1.cxx| 2 +
Source/cmContinueCommand.cxx | 21 +
Source/cmContinueCommand.h | 55 ++
Source/cmExecutionStatus.h | 7 +++
Source/cmForEachCommand.cxx| 4 ++
Source/cmIfCommand.cxx | 5 ++
Source/cmWhileCommand.cxx | 4 ++
Tests/RunCMake/CMakeLists.txt | 1 +
Tests/RunCMake/continue/CMakeLists.txt | 3 ++
Tests/RunCMake/continue/ContinueForeach-stdout.txt | 4 ++
Tests/RunCMake/continue/ContinueForeach.cmake | 8
.../continue/ContinueNestedForeach-stdout.txt | 6 +++
.../RunCMake/continue/ContinueNestedForeach.cmake | 13 +
Tests/RunCMake/continue/ContinueWhile-stdout.txt | 6 +++
Tests/RunCMake/continue/ContinueWhile.cmake| 10
Tests/RunCMake/continue/RunCMakeTest.cmake | 5 ++
17 files changed, 161 insertions(+)
create mode 100644 Help/command/continue.rst
create mode 100644 Source/cmContinueCommand.cxx
create mode 100644 Source/cmContinueCommand.h
create mode 100644 Tests/RunCMake/continue/CMakeLists.txt
create mode 100644 Tests/RunCMake/continue/ContinueForeach-stdout.txt
create mode 100644 Tests/RunCMake/continue/ContinueForeach.cmake
create mode 100644 Tests/RunCMake/continue/ContinueNestedForeach-stdout.txt
create mode 100644 Tests/RunCMake/continue/ContinueNestedForeach.cmake
create mode 100644 Tests/RunCMake/continue/ContinueWhile-stdout.txt
create mode 100644 Tests/RunCMake/continue/ContinueWhile.cmake
create mode 100644 Tests/RunCMake/continue/RunCMakeTest.cmake
diff --git a/Help/command/continue.rst b/Help/command/continue.rst
new file mode 100644
index 000..d377542
--- /dev/null
+++ b/Help/command/continue.rst
@@ -0,0 +1,7 @@
+continue
+
+
+Continue to the top of enclosing foreach or while loop.
+
+Continue allows the cmake script to abort the rest of a block in a foreach
+or while loop, and start at the top of the next iteration. See also break().
diff --git a/Source/cmBootstrapCommands1.cxx b/Source/cmBootstrapCommands1.cxx
index 5502609..4274d85 100644
--- a/Source/cmBootstrapCommands1.cxx
+++ b/Source/cmBootstrapCommands1.cxx
@@ -28,6 +28,7 @@
#include cmCMakePolicyCommand.cxx
#include cmCommandArgumentsHelper.cxx
#include cmConfigureFileCommand.cxx
+#include cmContinueCommand.cxx
#include cmCoreTryCompile.cxx
#include cmCreateTestSourceList.cxx
#include cmDefinePropertyCommand.cxx
@@ -70,6 +71,7 @@ void GetBootstrapCommands1(std::listcmCommand* commands)
commands.push_back(new cmCMakeMinimumRequired);
commands.push_back(new cmCMakePolicyCommand);
commands.push_back(new cmConfigureFileCommand);
+ commands.push_back(new cmContinueCommand);
commands.push_back(new cmCreateTestSourceList);
commands.push_back(new cmDefinePropertyCommand);
commands.push_back(new cmElseCommand);
diff --git a/Source/cmContinueCommand.cxx b/Source/cmContinueCommand.cxx
new file mode 100644
index 000..d516ad2
--- /dev/null
+++ b/Source/cmContinueCommand.cxx
@@ -0,0 +1,21 @@
+/*
+ CMake - Cross Platform Makefile Generator
+ Copyright 2000-2014 Kitware, Inc., Insight Software Consortium
+
+ Distributed under the OSI-approved BSD License (the License);
+ see accompanying file Copyright.txt for details.
+
+ This software is distributed WITHOUT ANY WARRANTY; without even the
+ implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ See the License for more information.
+*/
+#include cmContinueCommand.h
+
+// cmContinueCommand
+bool cmContinueCommand::InitialPass(std::vectorstd::string const,
+ cmExecutionStatus status)
+{
+ status.SetContinueInvoked(true);
+ return true;
+}
+
diff --git a/Source/cmContinueCommand.h b/Source/cmContinueCommand.h
new file mode 100644
index 000..093b14f
--- /dev/null
+++ b/Source/cmContinueCommand.h
@@ -0,0 +1,55 @@
+/*
+ CMake - Cross Platform Makefile Generator
+ Copyright 2000-2014 Kitware, Inc., Insight Software Consortium
+
+ Distributed under the OSI-approved BSD License (the License);
+ see accompanying file Copyright.txt for details.
+
+ This software is distributed WITHOUT ANY WARRANTY; without even the
+ implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ See the License for more information.
+*/
+#ifndef cmContinueCommand_h
+#define cmContinueCommand_h
+
+#include cmCommand.h
+
+/**
[cmake-developers] [PATCH v4 0/3] Add continue keyword
Hello, the current version now properly checks for proper nesting of the continue keyword. To detect new scope blocks like for example a function() I hoked into the Push/PopScope functions. I have some questions: 1) The Scope variable stack is held in a 'internal' structure that gets special treatment in the cmMakefile copy ctor. I don't know the implications of storing my loop block counter stack directly as member of cmMakefile. Could you please advise? 2) The error message for an inproperly nested continue looks like this: continue A CONTINUE command was found outside of a proper FOREACH or WHILE loop scope. where is the continue coming from? Is it part of a (too short) call stack trace? Also I noticed that the CMakeFile is still processed after the error is shown. Is this desired behavior? 3) The continue tests have a requirement for CMake version 3.1 in the CMakeLists.txt file. This needs to be bumped to 3.2 once the the version number got incremented to 3.2. 4) Is the new policy to reject misplaced break() commands really necessary? Thanks, Gregor https://github.com/gjasny/CMake/commits/feature/14013-continue-keyword *** BLURB HERE *** Gregor Jasny (3): Add continue keyword (#14013) Reject continue() without loop block (#14013) Reject break() without loop scope Help/command/continue.rst | 7 +++ Help/manual/cmake-policies.7.rst | 1 + Help/policy/CMP0055.rst| 17 +++ Source/cmBootstrapCommands1.cxx| 2 + Source/cmBreakCommand.cxx | 33 + Source/cmContinueCommand.cxx | 28 +++ Source/cmContinueCommand.h | 55 ++ Source/cmExecutionStatus.h | 7 +++ Source/cmForEachCommand.cxx| 12 + Source/cmIfCommand.cxx | 5 ++ Source/cmMakefile.cxx | 48 +++ Source/cmMakefile.h| 21 + Source/cmPolicies.cxx | 5 ++ Source/cmPolicies.h| 1 + Source/cmWhileCommand.cxx | 8 Tests/RunCMake/CMP0055/CMP0055-NEW-result.txt | 1 + Tests/RunCMake/CMP0055/CMP0055-NEW-stderr.txt | 4 ++ Tests/RunCMake/CMP0055/CMP0055-NEW.cmake | 4 ++ Tests/RunCMake/CMP0055/CMP0055-OLD-result.txt | 1 + Tests/RunCMake/CMP0055/CMP0055-OLD-stderr.txt | 1 + Tests/RunCMake/CMP0055/CMP0055-OLD.cmake | 4 ++ Tests/RunCMake/CMP0055/CMP0055-WARN-result.txt | 1 + Tests/RunCMake/CMP0055/CMP0055-WARN-stderr.txt | 9 Tests/RunCMake/CMP0055/CMP0055-WARN.cmake | 2 + Tests/RunCMake/CMP0055/CMakeLists.txt | 3 ++ Tests/RunCMake/CMP0055/RunCMakeTest.cmake | 5 ++ Tests/RunCMake/CMakeLists.txt | 3 ++ Tests/RunCMake/continue/CMakeLists.txt | 3 ++ .../RunCMake/continue/ContinueForEachInLists.cmake | 10 Tests/RunCMake/continue/ContinueForeach-stdout.txt | 4 ++ Tests/RunCMake/continue/ContinueForeach.cmake | 8 .../continue/ContinueNestedForeach-stdout.txt | 6 +++ .../RunCMake/continue/ContinueNestedForeach.cmake | 13 + Tests/RunCMake/continue/ContinueWhile-stdout.txt | 6 +++ Tests/RunCMake/continue/ContinueWhile.cmake| 10 .../RunCMake/continue/NoEnclosingBlock-result.txt | 1 + .../RunCMake/continue/NoEnclosingBlock-stderr.txt | 2 + Tests/RunCMake/continue/NoEnclosingBlock.cmake | 1 + .../continue/NoEnclosingBlockInFunction-result.txt | 1 + .../continue/NoEnclosingBlockInFunction-stderr.txt | 2 + .../continue/NoEnclosingBlockInFunction.cmake | 8 Tests/RunCMake/continue/RunCMakeTest.cmake | 8 Tests/RunCMake/return/CMakeLists.txt | 3 ++ Tests/RunCMake/return/ReturnFromForeach-result.txt | 1 + Tests/RunCMake/return/ReturnFromForeach.cmake | 10 Tests/RunCMake/return/RunCMakeTest.cmake | 3 ++ 46 files changed, 388 insertions(+) create mode 100644 Help/command/continue.rst create mode 100644 Help/policy/CMP0055.rst create mode 100644 Source/cmContinueCommand.cxx create mode 100644 Source/cmContinueCommand.h create mode 100644 Tests/RunCMake/CMP0055/CMP0055-NEW-result.txt create mode 100644 Tests/RunCMake/CMP0055/CMP0055-NEW-stderr.txt create mode 100644 Tests/RunCMake/CMP0055/CMP0055-NEW.cmake create mode 100644 Tests/RunCMake/CMP0055/CMP0055-OLD-result.txt create mode 100644 Tests/RunCMake/CMP0055/CMP0055-OLD-stderr.txt create mode 100644 Tests/RunCMake/CMP0055/CMP0055-OLD.cmake create mode 100644 Tests/RunCMake/CMP0055/CMP0055-WARN-result.txt create mode 100644 Tests/RunCMake/CMP0055/CMP0055-WARN-stderr.txt create mode 100644 Tests/RunCMake/CMP0055/CMP0055-WARN.cmake create mode 100644
[cmake-developers] [PATCH v4 2/3] Reject continue() without loop block (#14013)
To track the nested loop levels a counter is used.
It gets incremented while entering a loop block
(e.g. foreach or while) and gets decremented when leaving
the block. Because scope borders for example at function
borders must be taken into account the counter is put into
a stack. With every new scope an empty counter is pushed on
the stack, when leaving the scope the original value is restored.
This enables easy querying if the continue (and later also break)
command is properly nested within a loop scope.
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
Source/cmContinueCommand.cxx | 7
Source/cmForEachCommand.cxx| 8
Source/cmMakefile.cxx | 48 ++
Source/cmMakefile.h| 21 ++
Source/cmWhileCommand.cxx | 4 ++
Tests/RunCMake/CMakeLists.txt | 1 +
.../RunCMake/continue/ContinueForEachInLists.cmake | 10 +
.../RunCMake/continue/NoEnclosingBlock-result.txt | 1 +
.../RunCMake/continue/NoEnclosingBlock-stderr.txt | 2 +
Tests/RunCMake/continue/NoEnclosingBlock.cmake | 1 +
.../continue/NoEnclosingBlockInFunction-result.txt | 1 +
.../continue/NoEnclosingBlockInFunction-stderr.txt | 2 +
.../continue/NoEnclosingBlockInFunction.cmake | 8
Tests/RunCMake/continue/RunCMakeTest.cmake | 3 ++
Tests/RunCMake/return/CMakeLists.txt | 3 ++
Tests/RunCMake/return/ReturnFromForeach-result.txt | 1 +
Tests/RunCMake/return/ReturnFromForeach.cmake | 10 +
Tests/RunCMake/return/RunCMakeTest.cmake | 3 ++
18 files changed, 134 insertions(+)
create mode 100644 Tests/RunCMake/continue/ContinueForEachInLists.cmake
create mode 100644 Tests/RunCMake/continue/NoEnclosingBlock-result.txt
create mode 100644 Tests/RunCMake/continue/NoEnclosingBlock-stderr.txt
create mode 100644 Tests/RunCMake/continue/NoEnclosingBlock.cmake
create mode 100644
Tests/RunCMake/continue/NoEnclosingBlockInFunction-result.txt
create mode 100644
Tests/RunCMake/continue/NoEnclosingBlockInFunction-stderr.txt
create mode 100644 Tests/RunCMake/continue/NoEnclosingBlockInFunction.cmake
create mode 100644 Tests/RunCMake/return/CMakeLists.txt
create mode 100644 Tests/RunCMake/return/ReturnFromForeach-result.txt
create mode 100644 Tests/RunCMake/return/ReturnFromForeach.cmake
create mode 100644 Tests/RunCMake/return/RunCMakeTest.cmake
diff --git a/Source/cmContinueCommand.cxx b/Source/cmContinueCommand.cxx
index d516ad2..1cf2bc7 100644
--- a/Source/cmContinueCommand.cxx
+++ b/Source/cmContinueCommand.cxx
@@ -15,6 +15,13 @@
bool cmContinueCommand::InitialPass(std::vectorstd::string const,
cmExecutionStatus status)
{
+ if(!this-Makefile-IsLoopBlock())
+{
+this-SetError(A CONTINUE command was found outside of a proper
+ FOREACH or WHILE loop scope.);
+return false;
+}
+
status.SetContinueInvoked(true);
return true;
}
diff --git a/Source/cmForEachCommand.cxx b/Source/cmForEachCommand.cxx
index 465ddab..03d6590 100644
--- a/Source/cmForEachCommand.cxx
+++ b/Source/cmForEachCommand.cxx
@@ -27,6 +27,8 @@ IsFunctionBlocked(const cmListFileFunction lff, cmMakefile
mf,
// if this is the endofreach for this statement
if (!this-Depth)
{
+ cmMakefile::LoopBlockPop loopBlockPop(mf);
+
// Remove the function blocker for this scope or bail.
cmsys::auto_ptrcmFunctionBlocker
fb(mf.RemoveFunctionBlocker(this, lff));
@@ -77,6 +79,7 @@ IsFunctionBlocked(const cmListFileFunction lff, cmMakefile
mf,
}
}
}
+
// restore the variable to its prior value
mf.AddDefinition(this-Args[0],oldDef.c_str());
return true;
@@ -203,6 +206,8 @@ bool cmForEachCommand
}
this-Makefile-AddFunctionBlocker(f);
+ this-Makefile-PushLoopBlock();
+
return true;
}
@@ -246,5 +251,8 @@ bool
cmForEachCommand::HandleInMode(std::vectorstd::string const args)
}
this-Makefile-AddFunctionBlocker(f.release()); // TODO: pass auto_ptr
+
+ this-Makefile-PushLoopBlock();
+
return true;
}
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 8a8aadc..2795e83 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -171,6 +171,9 @@ void cmMakefile::Initialize()
// Protect the directory-level policies.
this-PushPolicyBarrier();
+ // push empty loop block
+ this-PushLoopBlockBarrier();
+
// By default the check is not done. It is enabled by
// cmListFileCache in the top level if necessary.
this-CheckCMP = false;
@@ -3293,6 +3296,47 @@ void cmMakefile::PopFunctionBlockerBarrier(bool
reportError)
}
//
+void cmMakefile::PushLoopBlock()
+{
+ if(this-LoopBlockCounter.empty())
+{
+assert(false);
+return;
+
[cmake-developers] [PATCH v4 3/3] Reject break() without loop scope
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
Help/manual/cmake-policies.7.rst | 1 +
Help/policy/CMP0055.rst| 17 +
Source/cmBreakCommand.cxx | 33 ++
Source/cmPolicies.cxx | 5
Source/cmPolicies.h| 1 +
Tests/RunCMake/CMP0055/CMP0055-NEW-result.txt | 1 +
Tests/RunCMake/CMP0055/CMP0055-NEW-stderr.txt | 4
Tests/RunCMake/CMP0055/CMP0055-NEW.cmake | 4
Tests/RunCMake/CMP0055/CMP0055-OLD-result.txt | 1 +
Tests/RunCMake/CMP0055/CMP0055-OLD-stderr.txt | 1 +
Tests/RunCMake/CMP0055/CMP0055-OLD.cmake | 4
Tests/RunCMake/CMP0055/CMP0055-WARN-result.txt | 1 +
Tests/RunCMake/CMP0055/CMP0055-WARN-stderr.txt | 9 +++
Tests/RunCMake/CMP0055/CMP0055-WARN.cmake | 2 ++
Tests/RunCMake/CMP0055/CMakeLists.txt | 3 +++
Tests/RunCMake/CMP0055/RunCMakeTest.cmake | 5
Tests/RunCMake/CMakeLists.txt | 1 +
17 files changed, 93 insertions(+)
create mode 100644 Help/policy/CMP0055.rst
create mode 100644 Tests/RunCMake/CMP0055/CMP0055-NEW-result.txt
create mode 100644 Tests/RunCMake/CMP0055/CMP0055-NEW-stderr.txt
create mode 100644 Tests/RunCMake/CMP0055/CMP0055-NEW.cmake
create mode 100644 Tests/RunCMake/CMP0055/CMP0055-OLD-result.txt
create mode 100644 Tests/RunCMake/CMP0055/CMP0055-OLD-stderr.txt
create mode 100644 Tests/RunCMake/CMP0055/CMP0055-OLD.cmake
create mode 100644 Tests/RunCMake/CMP0055/CMP0055-WARN-result.txt
create mode 100644 Tests/RunCMake/CMP0055/CMP0055-WARN-stderr.txt
create mode 100644 Tests/RunCMake/CMP0055/CMP0055-WARN.cmake
create mode 100644 Tests/RunCMake/CMP0055/CMakeLists.txt
create mode 100644 Tests/RunCMake/CMP0055/RunCMakeTest.cmake
diff --git a/Help/manual/cmake-policies.7.rst b/Help/manual/cmake-policies.7.rst
index 7074bd5..742fd63 100644
--- a/Help/manual/cmake-policies.7.rst
+++ b/Help/manual/cmake-policies.7.rst
@@ -112,3 +112,4 @@ All Policies
/policy/CMP0052
/policy/CMP0053
/policy/CMP0054
+ /policy/CMP0055
diff --git a/Help/policy/CMP0055.rst b/Help/policy/CMP0055.rst
new file mode 100644
index 000..1c7783d
--- /dev/null
+++ b/Help/policy/CMP0055.rst
@@ -0,0 +1,17 @@
+CMP0055
+---
+
+Disallow break() outside of loop contexts.
+
+CMake 3.1.0 and lower allowed to put a :command:`break` command outside of
+a loop context. This was undefined behavior.
+
+The OLD behavior for this policy is to allow
+:command:`break` to be placed outside of loop contexts.
+The NEW behavior for this policy is to issue an error if a misplaced break
+is found.
+
+This policy was introduced in CMake version 3.2.
+CMake version |release| warns when the policy is not set and uses
+OLD behavior. Use the cmake_policy command to set it to OLD or
+NEW explicitly.
diff --git a/Source/cmBreakCommand.cxx b/Source/cmBreakCommand.cxx
index b70e400..ae1781a 100644
--- a/Source/cmBreakCommand.cxx
+++ b/Source/cmBreakCommand.cxx
@@ -15,6 +15,39 @@
bool cmBreakCommand::InitialPass(std::vectorstd::string const,
cmExecutionStatus status)
{
+ if(!this-Makefile-IsLoopBlock())
+{
+bool issueMessage = true;
+cmOStringStream e;
+cmake::MessageType messageType = cmake::AUTHOR_WARNING;
+switch(this-Makefile-GetPolicyStatus(cmPolicies::CMP0055))
+ {
+ case cmPolicies::WARN:
+e (this-Makefile-GetPolicies()
+ -GetPolicyWarning(cmPolicies::CMP0055)) \n;
+break;
+ case cmPolicies::OLD:
+issueMessage = false;
+break;
+ case cmPolicies::REQUIRED_ALWAYS:
+ case cmPolicies::REQUIRED_IF_USED:
+ case cmPolicies::NEW:
+messageType = cmake::FATAL_ERROR;
+break;
+ }
+
+if (issueMessage)
+ {
+ e A BREAK command was found outside of a proper
+ FOREACH or WHILE loop scope.;
+ this-Makefile-IssueMessage(messageType, e.str());
+ if (messageType == cmake::FATAL_ERROR)
+{
+return false;
+}
+ }
+}
+
status.SetBreakInvoked(true);
return true;
}
diff --git a/Source/cmPolicies.cxx b/Source/cmPolicies.cxx
index a420f59..1527add 100644
--- a/Source/cmPolicies.cxx
+++ b/Source/cmPolicies.cxx
@@ -364,6 +364,11 @@ cmPolicies::cmPolicies()
CMP0054, CMP0054,
Only interpret if() arguments as variables or keywords when unquoted.,
3,1,0, cmPolicies::WARN);
+
+ this-DefinePolicy(
+CMP0055, CMP0055,
+Disallow break() outside of loop contexts.,
+3,2,0, cmPolicies::WARN);
}
cmPolicies::~cmPolicies()
diff --git a/Source/cmPolicies.h b/Source/cmPolicies.h
index 7c73da8..5e0bea0 100644
--- a/Source/cmPolicies.h
+++ b/Source/cmPolicies.h
@@ -111,6 +111,7 @@ public:
CMP0053, /// Simplify variable reference and escape sequence evaluation
CMP0054, /// Only interpret if() arguments as variables
/// or keywords when
Re: [cmake-developers] [CMake] target_include_directories target issue
FWD to developers list. I think this is a documentation issue.
Luis Felipe Dominguez Vega lfdoming...@estudiantes.uci.cu schrieb am Mon
Nov 17 2014 at 5:42:55 PM:
I can't see into the source code of cmake, into the
cmTargetIncludeDirectoriesCommand.cxx somethink like import the
INCLUDE_DIRECTORIES from target passed to target_include_directories, may
an
error in the documentation?
---
On Sunday 16 November 2014 11:56:05 AM Wojciech Mamrak wrote:
Hello,
the docs claim:
Specify include directories or targets to use when compiling a given
target.
Here is a little test of it. Project directory:
Foo
CMakeLists.txt
FooSrc
a.h
a.cpp
Bar
main.cpp
And CMakeLists.txt:
cmake_minimum_required(VERSION 3.0)
project(FooBar)
add_library(Foo FooSrc/a.h FooSrc/a.cpp)
target_include_directories(Foo PUBLIC G:/some_directory)
if (TARGET Foo)
message(Foo is a target!)
endif()
add_executable(Bar Bar/main.cpp)
target_include_directories(Bar PRIVATE Foo)
According to the docs, Bar's include directories should contain at
least G:/some_directory, but it contains
${PROJECT_SOURCE_DIR}/Foo. Why?
If I replace the last line with target_link_libraries(Bar PRIVATE
Foo), then Bar's include directories meet my expectations.
regards
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at http://www.kitware.com/
opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH v4 0/3] Add continue keyword
On 11/17/2014 02:00 PM, Gregor Jasny wrote: the current version now properly checks for proper nesting of the continue keyword. Cool, thanks. 1) The Scope variable stack is held in a 'internal' structure that gets special treatment in the cmMakefile copy ctor. I don't know the implications of storing my loop block counter stack directly as member of cmMakefile. Could you please advise? IIRC the cmMakefile copy ctor is used in CPack, but only in a context where nothing but the top-level scope is in place. You should be able to store the member in cmMakefile. 2) The error message for an inproperly nested continue looks like this: continue A CONTINUE command was found outside of a proper FOREACH or WHILE loop scope. where is the continue coming from? Is it part of a (too short) call stack trace? Also I noticed that the CMakeFile is still processed after the error is shown. Is this desired behavior? It comes from use of SetError and return false, the old error reporting mechanism. Instead you can do: this-Makefile-IssueMessage(cmake::FATAL_ERROR, ...); cmSystemTools::SetFatalErrorOccured(); return true; 3) The continue tests have a requirement for CMake version 3.1 in the CMakeLists.txt file. This needs to be bumped to 3.2 once the the version number got incremented to 3.2. You can use a dated version like 3.1.20141117 to request a dev version. 4) Is the new policy to reject misplaced break() commands really necessary? Yes, we need old code to continue to work even if it is wrong in this regard. 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
[cmake-developers] [PATCH] CPackRPM: unset temporary component variable fixed
Hi there,
First, I would like to thank you for your amazing work on CMake, CPack and
CTest.
I've been trying to make multiple RPMs using components, but it appears
that the component variables such
as CPACK_RPM_componentName_PACKAGE_REQUIRES are not correctly unset.
Worse, they are propagated to other components (that's how I found myself
having my devel RPM package requirements in my libs RPM package...)
Please find attach a small patch that fixes the problem (at least in my
case).
Thank you,
Gauthier
From aa90bab5dda090efac3ef58740a9c7d6297f35d3 Mon Sep 17 00:00:00 2001
From: Gauthier Lamaison gauthier.lamai...@gmail.com
Date: Mon, 17 Nov 2014 20:29:29 +0100
Subject: [PATCH] CPackRPM: unset temporary component variable fixed
---
Modules/CPackRPM.cmake | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index 66717ef..d2cb2ee 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -678,6 +678,8 @@ foreach(_RPM_SPEC_HEADER URL REQUIRES SUGGESTS PROVIDES OBSOLETES PREFIX CONFLIC
endif()
endif()
+ # Do not forget to unset previously set header (from previous component)
+ unset(TMP_RPM_${_RPM_SPEC_HEADER})
# Treat the RPM Spec keyword iff it has been properly defined
if(DEFINED CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER}_TMP)
# Transform NAME -- Name e.g. PROVIDES -- Provides
@@ -698,9 +700,7 @@ foreach(_RPM_SPEC_HEADER URL REQUIRES SUGGESTS PROVIDES OBSOLETES PREFIX CONFLIC
message(CPackRPM:Debug: User defined ${_PACKAGE_HEADER_NAME}:\n ${CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER}_TMP})
endif()
set(TMP_RPM_${_RPM_SPEC_HEADER} ${_PACKAGE_HEADER_NAME}: ${CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER}_TMP})
- else()
-# Do not forget to unset previously set header (from previous component)
-unset(TMP_RPM_${_RPM_SPEC_HEADER})
+unset(CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER}_TMP)
endif()
endforeach()
--
2.1.2
--
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] target_include_directories target issue
On 11/17/2014 02:09 PM, Daniel Pfeifer wrote: FWD to developers list. I think this is a documentation issue. Luis Felipe Dominguez Vega schrieb am Mon Nov 17 2014 at 5:42:55 PM: I can't see into the source code of cmake, into the cmTargetIncludeDirectoriesComm__and.cxx somethink like import the INCLUDE_DIRECTORIES from target passed to target_include_directories, may an error in the documentation? The command was first added with that capability but was never released like that due to ambiguity of target names and relative paths. I've fixed the docs: Help: target_include_directories does not allow target names http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1d22ee67 See commit message for details. 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
Re: [cmake-developers] [PATCH] CPackRPM: unset temporary component variable fixed
On 11/17/2014 02:46 PM, Gauthier Lamaison wrote: I've been trying to make multiple RPMs using components, but it appears that the component variables such as CPACK_RPM_componentName_PACKAGE_REQUIRES are not correctly unset. Worse, they are propagated to other components (that's how I found myself having my devel RPM package requirements in my libs RPM package...) Please find attach a small patch that fixes the problem (at least in my case). Thanks. This looks like a more complete version of commit v2.8.9~136^2: CPackRPM: avoid leakage of RPM directive from one component to another. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7321c94e CPackRPM bug - empty per-component REQUIRES http://www.cmake.org/Bug/view.php?id=13248 Would a CPackRPM maintainer please review the logic updates? 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
[cmake-developers] [CMake 0015254]: AUTOMOC ignores Q_OBJECT if preceded by non-whitespace characters
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15254
==
Reported By:Jonnhy Fisher
Assigned To:
==
Project:CMake
Issue ID: 15254
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2014-11-17 15:11 EST
Last Modified: 2014-11-17 15:11 EST
==
Summary:AUTOMOC ignores Q_OBJECT if preceded by
non-whitespace characters
Description:
A header file like
class A : public QObject
{Q_OBJECT
};
or
class A : public QObject
{
/* */ Q_OBJECT
};
with CMAKE_AUTOMOC will actually not run moc on that file, while
class A : public QObject
{
Q_OBJECT;
};
will run moc. Apparently there may only be whitespace in front of Q_OBJECT to
trigger automoc. This is not documented and kind of surprising.
Steps to Reproduce:
enable AUTOMOC
put a some none-whitespace before Q_OBJECT
==
Issue History
Date ModifiedUsername FieldChange
==
2014-11-17 15:11 Jonnhy Fisher New Issue
==
--
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] [PATCH] CPackRPM: unset temporary component variable fixed
2014-11-17 21:09 GMT+01:00 Brad King brad.k...@kitware.com: On 11/17/2014 02:46 PM, Gauthier Lamaison wrote: I've been trying to make multiple RPMs using components, but it appears that the component variables such as CPACK_RPM_componentName_PACKAGE_REQUIRES are not correctly unset. Worse, they are propagated to other components (that's how I found myself having my devel RPM package requirements in my libs RPM package...) Please find attach a small patch that fixes the problem (at least in my case). Thanks. This looks like a more complete version of commit v2.8.9~136^2: CPackRPM: avoid leakage of RPM directive from one component to another. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7321c94e CPackRPM bug - empty per-component REQUIRES http://www.cmake.org/Bug/view.php?id=13248 Would a CPackRPM maintainer please review the logic updates? Patch looks OK. Can you please apply it? Regards, Domen -- 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] [PATCH] CPackRPM: unset temporary component variable fixed
2014-11-17 23:05 GMT+01:00 Domen Vrankar domen.vran...@gmail.com: 2014-11-17 21:09 GMT+01:00 Brad King brad.k...@kitware.com: On 11/17/2014 02:46 PM, Gauthier Lamaison wrote: I've been trying to make multiple RPMs using components, but it appears that the component variables such as CPACK_RPM_componentName_PACKAGE_REQUIRES are not correctly unset. Worse, they are propagated to other components (that's how I found myself having my devel RPM package requirements in my libs RPM package...) Please find attach a small patch that fixes the problem (at least in my case). Thanks. This looks like a more complete version of commit v2.8.9~136^2: CPackRPM: avoid leakage of RPM directive from one component to another. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7321c94e CPackRPM bug - empty per-component REQUIRES http://www.cmake.org/Bug/view.php?id=13248 Would a CPackRPM maintainer please review the logic updates? Patch looks OK. Can you please apply it? Gauthier would you also be willing to write a test for this patch? You could extend the test that is already on master branch of git repository in directory cmake/Tests/CPackComponentsForAll. MyLibCPackConfig-IgnoreGroup.cmake.in contains the location where you can set component variables - if(CPACK_GENERATOR MATCHES RPM) section RunCPackVerifyResult.cmake contains checking of expected results (see the end of the script) Since the component variables logic is written in a for loop test of one variable would be enough. Thanks, Domen -- 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] Initial Attempt at Green Hill MULTI IDE Generator Support
Thanks for the feedback. I made some changes and rebased on the trunk.
The hunk in Modules/CMakeSystemSpecificInformation.cmake is now just removing
a blank line so it should not be needed.
Removed
+message(GHS-DetermineCompiler.cmake)
This looks like a leftover debugging message.
Removed
there are a few changes to find boost libraries with this generator.
[snip]
-if ( WIN32 AND Boost_USE_STATIC_LIBS AND NOT CYGWIN)
+if (Windows STREQUAL ${CMAKE_HOST_SYSTEM_NAME} AND
+Boost_USE_STATIC_LIBS AND NOT CYGWIN)
Why does the host affect the library prefix for binaries meant for the target
platform?
I'm still unsure if the WIN32 cmake variables is the target, platform or both.
I originally thought this check should be based on the host, but it should be
based on the target platform. I added a special case for the GHS Multi platform.
Some of the code is C++11. I'm not sure if that is an issue.
It is. We build on compilers that barely support C++98.
I removed usages of nullptr and std::anyof with a lamda expression.
Also, it skips the step where it determines the compiler by using the
force compiler macro. I don't see any other cmake module using this
functionality.
[snip]
+set(CMAKE_SYSTEM_NAME GHS-MULTI)
+set(CMAKE_SYSTEM_PROCESSOR ARM)
...
+include(CMakeForceCompiler)
+CMAKE_FORCE_CXX_COMPILER(cxarm GhsMultiArmCXX)
Those APIs are meant for use in a CMAKE_TOOLCHAIN_FILE.
The cmGlobalGhsMultiGenerator::EnableLanguage method should be able to take
care of those. This is the first time we've had a generator that locks to a
specific target platform (and implicitly cross-compiles).
Is CMAKE_SYSTEM_VERSION always hard-coded on a given system or should the user
be able to choose it in some way?
Platform/GHS-MULTI-C.cmake and Platform/GHS-MULTI-CXX.cmake have been moved
into the enable language method.
The cmake system version can be changed with the GHS_COMP_ROOT cache variable.
The version variable is not currently being used internally, since I've only
tested it on what I think is the latest version. There was a bug in the
previous use of find_program for CMAKE_MAKE_PROGRAM, where I thought the paths
were interpreted as a regular expression.
Geoffrey Viola
SOFTWARE ENGINEER
T
+1.435.755.2980
ext 1077
M
+1.215.896.6521
asirobots.com
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Wednesday, November 05, 2014 12:37 PM
To: Geoffrey Viola
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Initial Attempt at Green Hill MULTI IDE
Generator Support
On 11/05/2014 01:11 PM, Geoffrey Viola wrote:
I rebased and squashed the previous commits and made some new changes.
Thanks. Here are more comments.
The hunk in Modules/CMakeSystemSpecificInformation.cmake is now just removing a
blank line so it should not be needed.
+message(GHS-DetermineCompiler.cmake)
This looks like a leftover debugging message.
there are a few changes to find boost libraries with this generator.
[snip]
-if ( WIN32 AND Boost_USE_STATIC_LIBS AND NOT CYGWIN)
+if (Windows STREQUAL ${CMAKE_HOST_SYSTEM_NAME} AND
+Boost_USE_STATIC_LIBS AND NOT CYGWIN)
Why does the host affect the library prefix for binaries meant for the target
platform?
Some of the code is C++11. I'm not sure if that is an issue.
It is. We build on compilers that barely support C++98.
Also, it skips the step where it determines the compiler by using the
force compiler macro. I don't see any other cmake module using this
functionality.
[snip]
+set(CMAKE_SYSTEM_NAME GHS-MULTI)
+set(CMAKE_SYSTEM_PROCESSOR ARM)
...
+include(CMakeForceCompiler)
+CMAKE_FORCE_CXX_COMPILER(cxarm GhsMultiArmCXX)
Those APIs are meant for use in a CMAKE_TOOLCHAIN_FILE.
The cmGlobalGhsMultiGenerator::EnableLanguage method should be able to take
care of those. This is the first time we've had a generator that locks to a
specific target platform (and implicitly cross-compiles).
Is CMAKE_SYSTEM_VERSION always hard-coded on a given system or should the user
be able to choose it in some way?
Thanks,
-Brad
This message contains confidential information and is intended only for the
recipient. If you are not the named addressee you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately if you
have received this e-mail by mistake and delete this e-mail from your system.
Finally, the recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage caused by
any virus transmitted by this email.
0001-Added-some-support-for-a-Green-Hill-MULTI.patch
Description: 0001-Added-some-support-for-a-Green-Hill-MULTI.patch
--
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:
Re: [cmake-developers] [PATCH] CPackRPM: unset temporary component variable fixed
Gauthier would you also be willing to write a test for this patch? Sure ! I'll dig into that. You could extend the test that is already on master branch of git repository in directory cmake/Tests/CPackComponentsForAll. MyLibCPackConfig-IgnoreGroup.cmake.in contains the location where you can set component variables - if(CPACK_GENERATOR MATCHES RPM) section RunCPackVerifyResult.cmake contains checking of expected results (see the end of the script) Found it. Thanks, Gauthier -- 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] New command 'file(LOCK_DIRECTORY ...)'
On 17-Nov-14 18:06, Brad King wrote:
Yes, please change to that so a proper error can be produced for the new
API when 123xyz is given as a timeout, for example.
Function added cmSystemTools::StringToInt
Please look at adding a case to the test suite for this. An outer
process could take the lock and then execute_process a child that
tries to take the lock with a timeout. Then check that it fails
as expected.
Done
Ruslo
From 9a3e5728173d2b5e4381d3c65556534298f7bb27 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Tue, 18 Nov 2014 02:32:27 +0300
Subject: [PATCH 1/7] Add function cmSystemTools::StringToInt
---
Source/cmSystemTools.cxx | 7 +++
Source/cmSystemTools.h | 3 +++
2 files changed, 10 insertions(+)
diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 3247f7f..9664983 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -2925,3 +2925,10 @@ std::vectorstd::string cmSystemTools::tokenize(const
std::string str,
}
return tokens;
}
+
+//
+bool cmSystemTools::StringToInt(const char* str, int* value) {
+ char unused;
+ const int result = sscanf(str, %d%c, value, unused);
+ return (result == 1);
+}
diff --git a/Source/cmSystemTools.h b/Source/cmSystemTools.h
index 4455dd1..763389b 100644
--- a/Source/cmSystemTools.h
+++ b/Source/cmSystemTools.h
@@ -458,6 +458,9 @@ public:
static std::vectorstd::string tokenize(const std::string str,
const std::string sep);
+ /** Convert string to int. Expected that the whole string is an integer */
+ static bool StringToInt(const char* str, int* value);
+
#ifdef _WIN32
struct WindowsFileRetry
{
--
2.1.1
From 9e7e463d51a8944c8951540114e0e34824a239f5 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Tue, 18 Nov 2014 02:33:46 +0300
Subject: [PATCH 2/7] Add class cmFileLockResult
---
Source/cmFileLockResult.cxx | 111
Source/cmFileLockResult.h | 85 +
2 files changed, 196 insertions(+)
create mode 100644 Source/cmFileLockResult.cxx
create mode 100644 Source/cmFileLockResult.h
diff --git a/Source/cmFileLockResult.cxx b/Source/cmFileLockResult.cxx
new file mode 100644
index 000..045e7ee
--- /dev/null
+++ b/Source/cmFileLockResult.cxx
@@ -0,0 +1,111 @@
+/*
+ CMake - Cross Platform Makefile Generator
+ Copyright 2014 Ruslan Baratov
+
+ Distributed under the OSI-approved BSD License (the License);
+ see accompanying file Copyright.txt for details.
+
+ This software is distributed WITHOUT ANY WARRANTY; without even the
+ implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ See the License for more information.
+*/
+
+#include cmFileLockResult.h
+
+#include errno.h
+
+cmFileLockResult cmFileLockResult::MakeOk()
+{
+ return cmFileLockResult(OK, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeSystem()
+{
+#if defined(_WIN32)
+ const Error lastError = GetLastError();
+#else
+ const Error lastError = errno;
+#endif
+ return cmFileLockResult(SYSTEM, lastError);
+}
+
+cmFileLockResult cmFileLockResult::MakeTimeout()
+{
+ return cmFileLockResult(TIMEOUT, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeAlreadyLocked()
+{
+ return cmFileLockResult(ALREADY_LOCKED, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeInternal()
+{
+ return cmFileLockResult(INTERNAL, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeNoFunction()
+{
+ return cmFileLockResult(NO_FUNCTION, 0);
+}
+
+bool cmFileLockResult::IsOk() const
+{
+ return this-Type == OK;
+}
+
+std::string cmFileLockResult::GetOutputMessage() const
+{
+ switch (this-Type)
+{
+case OK:
+ return 0;
+case SYSTEM:
+#if defined(_WIN32)
+ {
+ char* errorText = NULL;
+
+ // http://stackoverflow.com/a/455533/2288008
+ DWORD flags = FORMAT_MESSAGE_FROM_SYSTEM |
+ FORMAT_MESSAGE_ALLOCATE_BUFFER |
+ FORMAT_MESSAGE_IGNORE_INSERTS;
+ ::FormatMessageA(
+ flags,
+ NULL,
+ this-ErrorValue,
+ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
+ (LPSTR)errorText,
+ 0,
+ NULL
+ );
+
+ if (errorText != NULL)
+{
+const std::string message = errorText;
+::LocalFree(errorText);
+return message;
+}
+ else
+{
+return Internal error (FormatMessageA failed);
+}
+ }
+#else
+ return strerror(this-ErrorValue);
+#endif
+case TIMEOUT:
+ return Timeout reached;
+case ALREADY_LOCKED:
+ return File already locked;
+case NO_FUNCTION:
+ return 'GUARD FUNCTION' not used in function definition;
+case INTERNAL:
+
Re: [cmake-developers] Failing CMake WinStorePhone tests
Hi David, Can you give me some information on your current setup? What build of VS do you have installed, which options? I think that the detection logic for the tests is missing some cases. I'm guessing that this is similar to what I recently fixed in CMake for the express editions, the same detection logic might need to be moved over to the test script. -Original Message- From: David Cole [mailto:dlrd...@aol.com] Sent: Friday, November 14, 2014 10:42 To: Gilles Khouzam Cc: Brad King; cmake-developers@cmake.org Subject: Re: [cmake-developers] Failing CMake WinStorePhone tests I was hoping you'd say that! :-) On Fri, Nov 14, 2014 at 12:23 PM, Gilles Khouzam gilles.khou...@microsoft.com wrote: Hi David, Let me take a look at what's going on. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Friday, November 14, 2014 08:38 To: David Cole Cc: cmake-developers@cmake.org; Gilles Khouzam Subject: Re: [cmake-developers] Failing CMake WinStorePhone tests On 11/14/2014 11:27 AM, David Cole via cmake-developers wrote: Should I expect these tests to pass using Ninja, or is that beyond the scope of the WinStorePhone support...? The VS generator is needed for the feature, but the tests that are failing hard-code use of specific Visual Studio generators regardless of the main generator being tested. I'll defer to Gilles as for what the problem might be. -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
[CMake] CTest XML format
Hi all, we want to archive our unittest results, code coverage etc. when we release a product. Therefor we want to store the generated XML files in TestLink. However when we need to look at the results again we need to display them somehow. So I have some questions regarding the format: 1.) I found this link: http://public.kitware.com/Wiki/CDash:XML What is missing for me at the moment is a description of the Measurement Value field in Test.xml My files contain values using encoding=Base64 and compression=gzip. I base64 decoded these values and tried to gunzip, but it is not a valid gzip file. I also tried pure deflate, but also no success. So how are these values encoded/compressed in detail? 2.) Is there a way to re-import these values later on into CDash for inspection? 3.) Is there another GUI for inspecting these files? (Configure, Build and Test.xml) 4.) Do you know of any import filter for TestLink, so that the results could be directly be shown inside TestLink? http://testlink.org/ regards, Gerhard. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] can I make an AUTOMOC generated file depend on something ?
Hi,
I have a project where Qt is used, so I use AUTOMOC.
However I have something special:
My Qt class implementation needs another (external) Qt implemented source, which
I have packed as tar.bz2 file.
I have a rule which shall extract the .tar.bz2 file, which works nicely.
However, the AUTOMOC generates the moc_ file BEFORE the rule to extract the
.tar.bz2 file
triggers, which means moc can not include some headers which are inside this
tar file
and the result is wrong.
I have something like (excerpt):
add_library(MYLIB MODULE source.cxx)
set_target_properties(MYLIB PROPERTIES AUTOMOC TRUE)
add_custom_command(OUTPUT header.h
COMMAND ${CMAKE_COMMAND} -E tar xf
${CMAKE_CURRENT_SOURCE_DIR}/includes.tar.bz2
COMMAND ${CMAKE_COMMAND} -E tar vxf
${CMAKE_CURRENT_SOURCE_DIR}/${TARFILE}
COMMAND ${CMAKE_COMMAND} -E touch_nocreate header.h
DEPENDS ${TARFILE})
add_custom_target(data_lib DEPENDS header.h)
add_dependencies(${TARGET} data_lib)
What rules can I add so that the tar extraction is done BEFORE the moc
generation ?
--
Best Regards/Schöne Grüße
Martin
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] target_include_directories target issue
That's because the include directory is obtained in dependends. The
documentation say that when the library is imported by dependends of a target,
the dependant target obtain all the PUBLIC and INTERFACE include directories,
so, with the command
target_include_directories(Bar PRIVATE Foo)
You are populating the property INCLUDE_DIRECTORIES of the target Bar, only
with Foo. Just figure it, how cmake can guess that the Bar target depends of
Foo target, you are only telling that add the DIRECTORY Foo to the PRIVATE
INCLUDE_DIRECTORIES of Bar. The command
target_include_directories
In a reduced form is target_include_directories (target [PRIVATE | PUBLIC |
INTERFACE] directories_to_include_not_targets
So, if you think that the command is getting the Foo as a target, noup, is
getting as a directory.
---
On Sunday 16 November 2014 11:56:05 AM Wojciech Mamrak wrote:
Hello,
the docs claim:
Specify include directories or targets to use when compiling a given
target.
Here is a little test of it. Project directory:
Foo
CMakeLists.txt
FooSrc
a.h
a.cpp
Bar
main.cpp
And CMakeLists.txt:
cmake_minimum_required(VERSION 3.0)
project(FooBar)
add_library(Foo FooSrc/a.h FooSrc/a.cpp)
target_include_directories(Foo PUBLIC G:/some_directory)
if (TARGET Foo)
message(Foo is a target!)
endif()
add_executable(Bar Bar/main.cpp)
target_include_directories(Bar PRIVATE Foo)
According to the docs, Bar's include directories should contain at
least G:/some_directory, but it contains
${PROJECT_SOURCE_DIR}/Foo. Why?
If I replace the last line with target_link_libraries(Bar PRIVATE
Foo), then Bar's include directories meet my expectations.
regards
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] library dependcies and add_library(OBJECT)
Hello! I'm playing with add_library(OBJECT) operation. Everything works nice but then I have one library that uses some external library. An attempt to add target_link_libraries here results in failure, because I don't build and library, only object files. But now comes the problem, how do I notify target that uses my library that it should include additional external library as dependency? Of course in the simplest case I can provide target_link_libraries for the executable, but I'd prefer to keep this setting in the CMakeLists.txt for the library. In hope to clarify the above, suppose that we have project with sources located in directories A, B and C. The final executable is built using objects from these directories. In each of directories I place CMakeLists.txt containing add_library(X OBJECT x.c y.c). Then in CMakeLists.txt for the executable I put line add_executable(my_prog $TARGET_OBJECTS:A $TARGET_OBJECTS:B $TARGET_OBJECTS:C) Now, suppose files in B use external library libssl. What should I add to B/CMakeLists.txt to successfully build my executable? -- Andrei Voropaev -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] target_include_directories target issue
Hello,
Just figure it, how cmake can guess that the Bar target depends of Foo
target, you are only telling that add the DIRECTORY Foo to the PRIVATE
INCLUDE_DIRECTORIES of Bar.
Because the docs say so:
Specify include directories or targets to use when compiling a given target..
regards
2014-11-17 9:21 GMT+01:00 Luis Felipe Dominguez Vega
lfdoming...@estudiantes.uci.cu:
That's because the include directory is obtained in dependends. The
documentation say that when the library is imported by dependends of a target,
the dependant target obtain all the PUBLIC and INTERFACE include directories,
so, with the command
target_include_directories(Bar PRIVATE Foo)
You are populating the property INCLUDE_DIRECTORIES of the target Bar, only
with Foo. Just figure it, how cmake can guess that the Bar target depends of
Foo target, you are only telling that add the DIRECTORY Foo to the PRIVATE
INCLUDE_DIRECTORIES of Bar. The command
target_include_directories
In a reduced form is target_include_directories (target [PRIVATE | PUBLIC |
INTERFACE] directories_to_include_not_targets
So, if you think that the command is getting the Foo as a target, noup, is
getting as a directory.
---
On Sunday 16 November 2014 11:56:05 AM Wojciech Mamrak wrote:
Hello,
the docs claim:
Specify include directories or targets to use when compiling a given
target.
Here is a little test of it. Project directory:
Foo
CMakeLists.txt
FooSrc
a.h
a.cpp
Bar
main.cpp
And CMakeLists.txt:
cmake_minimum_required(VERSION 3.0)
project(FooBar)
add_library(Foo FooSrc/a.h FooSrc/a.cpp)
target_include_directories(Foo PUBLIC G:/some_directory)
if (TARGET Foo)
message(Foo is a target!)
endif()
add_executable(Bar Bar/main.cpp)
target_include_directories(Bar PRIVATE Foo)
According to the docs, Bar's include directories should contain at
least G:/some_directory, but it contains
${PROJECT_SOURCE_DIR}/Foo. Why?
If I replace the last line with target_link_libraries(Bar PRIVATE
Foo), then Bar's include directories meet my expectations.
regards
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CTest XML format
Hi, I was able to figure out my first question. The first two bytes of the binary data was 78 9C. This is the file header of Zlib data with default compression. So by adding the correct gzip header manually you can decompress it. Assume the base64 data from XML is saved in ~/test.base64 you can unpack the data this way: base64 -d ~/test.base64 ~/test.bin printf \x1f\x8b\x08\x00\x00\x00\x00\x00 | cat - ~/test.bin | gzip -dc Am 17.11.2014 11:20, schrieb Gerhard Gappmeier: Hi all, we want to archive our unittest results, code coverage etc. when we release a product. Therefor we want to store the generated XML files in TestLink. However when we need to look at the results again we need to display them somehow. So I have some questions regarding the format: 1.) I found this link: http://public.kitware.com/Wiki/CDash:XML What is missing for me at the moment is a description of the Measurement Value field in Test.xml My files contain values using encoding=Base64 and compression=gzip. I base64 decoded these values and tried to gunzip, but it is not a valid gzip file. I also tried pure deflate, but also no success. So how are these values encoded/compressed in detail? 2.) Is there a way to re-import these values later on into CDash for inspection? 3.) Is there another GUI for inspecting these files? (Configure, Build and Test.xml) 4.) Do you know of any import filter for TestLink, so that the results could be directly be shown inside TestLink? http://testlink.org/ regards, Gerhard. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] Diagnostics for unclosed generator expressions?
Hi,
Today I learned the hard way that cmake does not provide any diagnostic about
unclosed generator expressions.
Consider the following:
add_test(
NAME generator_expression_unclosed
COMMAND
${CMAKE_COMMAND} -E echo $0:Unclosed expression gives a warning?
)
cmake happily accepts this without any diagnostic, whereas regular variables
are diagnosed correctly:
message(STATUS ${test)
gives:
Syntax error in cmake code at
/home/zing/scratch/cmake_testbed/CMakeLists.txt:143
when parsing string
${unclosed
syntax error, unexpected $end, expecting } (10)
Should I file a bug report on this issue?
Cheers,
Johannes
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] Packaging command-line + GUI tools on OS X
Hi all, I am trying to package a set of command line tools and some graphical tools, sharing the same libraries. Given how Apple wants people to use relocatable .app bundles, but advises to put command line tools in their usual *nix paths, I came up with the following intended paths for my files: /Applications /foo.app /Contents /MacOS foo (linked to ../lib/bar.dylib) /lib - (symlink to INSTALL_ROOT/lib INSTALL_ROOT /lib bar.dylib /bin baz (linked to ../lib/bar.dylib) Here, foo.app is a graphical app, bar a dynamic library and baz a command line app. I would like users to have the freedom to install into any directory they like (but default would be /usr or /usr/local). Especially because I would like to be able to deploy multiple versions of the tool suite simultaneously. The suggested approach with the symlink causes the .app bundles to be relocatable, as long as the shared libraries are not moved. This is a compromise I am willing to make; the alternative is to have a private copy of each shared library per .app, defeating the point of shared libraries. As we have 5 .apps, and 80MB of shared libraries, making copies is not acceptable. Is there a way to achieve the intended setup using CPack? I have been trying to use the PackageMaker generator, but I do not see how I could add in the symlink to the INSTALL_ROOT/lib dir, as this is path is only known when the package is installed. Early experiments with the CPACK_POSTFLIGHT_SCRIPT caused the installer to display the (unhelpful) error message “Something went wrong”, and I am not sure this feature is supported for new versions of OS X. Also, CMake complains about installing files in the absolute path /Applications; I am unsure if I can safely ignore these warnings. I hope someone can point me in the right direction. Best regards, Sjoerd Cranen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] target_include_directories target issue
I can't see into the source code of cmake, into the
cmTargetIncludeDirectoriesCommand.cxx somethink like import the
INCLUDE_DIRECTORIES from target passed to target_include_directories, may an
error in the documentation?
---
On Sunday 16 November 2014 11:56:05 AM Wojciech Mamrak wrote:
Hello,
the docs claim:
Specify include directories or targets to use when compiling a given
target.
Here is a little test of it. Project directory:
Foo
CMakeLists.txt
FooSrc
a.h
a.cpp
Bar
main.cpp
And CMakeLists.txt:
cmake_minimum_required(VERSION 3.0)
project(FooBar)
add_library(Foo FooSrc/a.h FooSrc/a.cpp)
target_include_directories(Foo PUBLIC G:/some_directory)
if (TARGET Foo)
message(Foo is a target!)
endif()
add_executable(Bar Bar/main.cpp)
target_include_directories(Bar PRIVATE Foo)
According to the docs, Bar's include directories should contain at
least G:/some_directory, but it contains
${PROJECT_SOURCE_DIR}/Foo. Why?
If I replace the last line with target_link_libraries(Bar PRIVATE
Foo), then Bar's include directories meet my expectations.
regards
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] disable interactive image ?
Hi, after upgrading to cdash 2.2.2 I'm having issues re: the Interactive Image display for image diffs when there are more than 1 set of images in a test. Here's an example: http://visit.cdash.lbl.gov/testDetails.php?test=1028748build=3413 It looks like it may be grabbing the wrong valid image? and the widget is only displayed on the first test so we can't see valid images for the rest of the tests. That's new, in cdash 2.2.0 things worked OK. In 2.2.2 is there a way to return to the cdash 2.2.0 behavior (note: I can't downgrade because of security issues)? Is there a way to turn on the widget for each set of diffs? Burlen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] ARGV to ARGN translation debugging
Hey all,
I know that ARGV is all arguments, and ARGN is all arguments past the last
expected argument. I find myself in a weird situation with these, where
identical ARGV's in the same function lead to different ARGN's. The
relevant code in the CMake script is below
FUNCTION(MY_FUNC_NAME EXE_NAME)
MESSAGE(FINAL ARGV: ${ARGV})
MESSAGE(FINAL ARGN: ${ARGN})
.
ENDFUNCTION()
Two different calls lead to the following outputs
FINAL ARGV:
Multifield_Repartition;SOURCES;multifield_repartition.cpp;COMM;mpi;serial;STANDARD_PASS_OUTPUT;NUM_MPI_PROCS;4;FAIL_REGULAR_EXPRESSION;TEST
FAILED;PASS_REGULAR_EXPRESSION;TEST
PASSED;ARGS;--num_particles=50;--num_dimensions=2
FINAL ARGN:
FINAL ARGV:
Multifield_Repartition;SOURCES;multifield_repartition.cpp;COMM;mpi;serial;STANDARD_PASS_OUTPUT;NUM_MPI_PROCS;4;FAIL_REGULAR_EXPRESSION;TEST
FAILED;PASS_REGULAR_EXPRESSION;TEST
PASSED;ARGS;--num_particles=50;--num_dimensions=2
FINAL ARGN:
SOURCES;multifield_repartition.cpp;COMM;mpi;serial;STANDARD_PASS_OUTPUT;NUM_MPI_PROCS;4;FAIL_REGULAR_EXPRESSION;TEST
FAILED;PASS_REGULAR_EXPRESSION;TEST
PASSED;ARGS;--num_particles=50;--num_dimensions=2
The formatting in an email is weird, but a diff on these outputs is empty
on the argv lines, the only difference is in the ARGN.
So I could use the answer to either of the following questions:
1) How can the same ARGV to the same function give different ARGN's? My
feeling is that the answer is never, it's something in how the MESSAGE
command displays lists.
2) How can we display lists in a way that allows us to see the differences
between them? That is, is there some function which I can replace MESSAGE
with in order to see the discrepancy between these two lists?
More info available on request, I'm still new enough to CMake to not know
what to report, the CMake versions used are git head (
3609fceee75b4f3751a702ac0a7f21e5cbd67a0a ) and a release (2.8.12.2),
problem is identical in each case.
Best,
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:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] ARGV to ARGN translation debugging
On 11/17/2014 1:44 PM, Joe wrote:
1) How can the same ARGV to the same function give different ARGN's? My
feeling is that the answer is never, it's something in how the MESSAGE
command displays lists.
2) How can we display lists in a way that allows us to see the
differences between them? That is, is there some function which I can
replace MESSAGE with in order to see the discrepancy between these two
lists?
To me it looks like in the first call all of this stuff:
Multifield_Repartition;SOURCES;multifield_repartition.cpp;COMM;mpi;serial;STANDARD_PASS_OUTPUT;NUM_MPI_PROCS;4;FAIL_REGULAR_EXPRESSION;TEST
FAILED;PASS_REGULAR_EXPRESSION;TEST
PASSED;ARGS;--num_particles=50;--num_dimensions=2
is crammed into one variable.
It might be clearer if you changed your messages to do this:
MESSAGE(FINAL EXE_NAME: ${EXE_NAME})
MESSAGE(FINAL ARGV: ${ARGV})
MESSAGE(FINAL ARGN: ${ARGN})
Most likely it was called quoted?
my_func(lots of stuff;foo;bar)
vs
my_func(lots of stuff foo bar)
-Bill
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] target_include_directories target issue
On 11/17/2014 02:09 PM, Daniel Pfeifer wrote: FWD to developers list. I think this is a documentation issue. Luis Felipe Dominguez Vega schrieb am Mon Nov 17 2014 at 5:42:55 PM: I can't see into the source code of cmake, into the cmTargetIncludeDirectoriesComm__and.cxx somethink like import the INCLUDE_DIRECTORIES from target passed to target_include_directories, may an error in the documentation? The command was first added with that capability but was never released like that due to ambiguity of target names and relative paths. I've fixed the docs: Help: target_include_directories does not allow target names http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1d22ee67 See commit message for details. 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
Re: [CMake] ARGV to ARGN translation debugging
Hey all,
Looks like Bill's got it. Thanks Bill. FYI, this was done as part of doing
parameter sweeps (run tests with all combinations of various parameters and
settings), when it has been made pretty it may get committed back.
Best,
David
On Mon, Nov 17, 2014 at 11:44 AM, Bill Hoffman bill.hoff...@kitware.com
wrote:
On 11/17/2014 1:44 PM, Joe wrote:
1) How can the same ARGV to the same function give different ARGN's? My
feeling is that the answer is never, it's something in how the MESSAGE
command displays lists.
2) How can we display lists in a way that allows us to see the
differences between them? That is, is there some function which I can
replace MESSAGE with in order to see the discrepancy between these two
lists?
To me it looks like in the first call all of this stuff:
Multifield_Repartition;SOURCES;multifield_repartition.cpp;COMM;mpi;
serial;STANDARD_PASS_OUTPUT;NUM_MPI_PROCS;4;FAIL_REGULAR_EXPRESSION;TEST
FAILED;PASS_REGULAR_EXPRESSION;TEST PASSED;ARGS;--num_particles=
50;--num_dimensions=2
is crammed into one variable.
It might be clearer if you changed your messages to do this:
MESSAGE(FINAL EXE_NAME: ${EXE_NAME})
MESSAGE(FINAL ARGV: ${ARGV})
MESSAGE(FINAL ARGN: ${ARGN})
Most likely it was called quoted?
my_func(lots of stuff;foo;bar)
vs
my_func(lots of stuff foo bar)
-Bill
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at http://www.kitware.com/
opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] can I make an AUTOMOC generated file depend on something ?
Martin Koller wrote: What rules can I add so that the tar extraction is done BEFORE the moc generation ? You can add depends in the AUTOGEN_TARGET_DEPENDS target property of particular targets. http://www.cmake.org/cmake/help/v3.0/prop_tgt/AUTOGEN_TARGET_DEPENDS.html Please try that out. It will require you to set it on each target. If that's too suboptimal, we can think about adding an additional convenience interface. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] library dependcies and add_library(OBJECT)
avo...@mail.ru wrote: What should I add to B/CMakeLists.txt to successfully build my executable? You might be able to add an INTERFACE library and populate its INTERFACE_SOURCES using the target_sources command: http://www.cmake.org/cmake/help/v3.1/command/target_sources.html http://www.cmake.org/cmake/help/v3.1/manual/cmake-buildsystem.7.html#interface-libraries Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] CMake 3.x not respecting IMPORTED_LOCATION_CONFIG properties
Hello,
Until recently, I was making use of the 'debug' and 'optimized' keywords to
select the config-specific versions of external dependencies to link in, i.e.
if I wanted to link Bar into Foo, I would use:
target_link_libraries (Foo DEBUG ${Bar_Debug} OPTIMIZED ${Bar_Release})
Now I have added my own custom configuration to CMAKE_CONFIGURATION_TYPES,
let's call it Custom, and I want Foo, when built in Custom config, to link
against the Custom variant of Bar. I did some reading and came across IMPORTED
targets, which seem designed for this purpose, so I added new lines like the
following:
add_library (Bar STATIC IMPORTED GLOBAL)
set_property (TARGET Bar PROPERTY IMPORTED_LOCATION_DEBUG
/path/to/Debug/Bar.lib)
set_property (TARGET Bar PROPERTY IMPORTED_LOCATION_RELEASE
/path/to/Release/Bar.lib)
set_property (TARGET Bar PROPERTY IMPORTED_LOCATION_CUSTOM
/path/to/Custom/Bar.lib)
target_link_libraries (Foo Bar)
However, when I open the generated Visual Studio project, I see Bar-NOTFOUND
in the linker inputs. If I add the line:
set_property (TARGET Bar PROPERTY IMPORTED_LOCATION /path/to/Release/Bar.lib)
Then the linker inputs are resolved correctly, but of course all of my
configurations of Foo are now going to link against the same Release
configuration of Bar.
Is this a bug, or am I simply not using this feature correctly? I tried both
3.0.1 and 3.1rc2 on Windows.
Thanks,
Parag Chandra
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] target_include_directories target issue
Thanks Brad, that explains everything. regards 2014-11-17 20:50 GMT+01:00 Brad King brad.k...@kitware.com: On 11/17/2014 02:09 PM, Daniel Pfeifer wrote: FWD to developers list. I think this is a documentation issue. Luis Felipe Dominguez Vega schrieb am Mon Nov 17 2014 at 5:42:55 PM: I can't see into the source code of cmake, into the cmTargetIncludeDirectoriesComm__and.cxx somethink like import the INCLUDE_DIRECTORIES from target passed to target_include_directories, may an error in the documentation? The command was first added with that capability but was never released like that due to ambiguity of target names and relative paths. I've fixed the docs: Help: target_include_directories does not allow target names http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1d22ee67 See commit message for details. 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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v3.1.0-rc2-668-gc2a87de
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 c2a87deafe277348e7fba5ffc55d67f7624dce9b (commit)
via 557aef0b94c86d13e802e6e8e34a491304d7be2f (commit)
via e15a7075b58aef6fe7b6eb56f810d0f33bc31feb (commit)
via 67bd514adce689f4c7f537cdc446c01f7373f5a5 (commit)
via ef42e57d470db499a41c8bca695391c3e3e5cb86 (commit)
via 592644c42c58312aadf1fd1b28e95c7f0fbbb2f8 (commit)
via 2d75d7e56bc00c9abe51d39c4306084b24fe8cd5 (commit)
via f42d86f0b834c73b28a919ef1b4279753a6ec1bd (commit)
via f281ae01a2b89d8a7d327b3f6e73b727195d8dfd (commit)
via d5eae5563f99fb28c99695fb4886f1bd40d98414 (commit)
via 4d1fedf46e9cbdb388728c9a986cbf89db810c73 (commit)
via fe5d6e8c0f2e37bac0621a3b976d95c471891f38 (commit)
from f77a1b1f89fd74036cb98f1d0ba45e34d8c5f02f (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 -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c2a87deafe277348e7fba5ffc55d67f7624dce9b
commit c2a87deafe277348e7fba5ffc55d67f7624dce9b
Merge: f77a1b1 557aef0
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 17 09:37:43 2014 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Nov 17 09:37:43 2014 -0500
Merge topic 'custom-command-byproducts' into next
557aef0b ExternalProject: Add options to specify BYPRODUCTS (#14963)
e15a7075 Add an option for explicit BYPRODUCTS of custom commands (#14963)
67bd514a Ninja: Refactor restat to be a string internally
ef42e57d Ninja: Use a TARGET_FILE variable to hold the link output file
592644c4 Tests/BuildDepends: Drop unneeded help for Ninja
2d75d7e5 Help: Add notes for topic 'console-pool'
f42d86f0 Ninja: Implement USES_TERMINAL using the console pool if available
f281ae01 Ninja: Remove unused declaration
d5eae556 Ninja: factor out the test for console pool support
4d1fedf4 Give the interactive cache editor the USES_TERMINAL property
fe5d6e8c Add USES_TERMINAL option for custom commands
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=557aef0b94c86d13e802e6e8e34a491304d7be2f
commit 557aef0b94c86d13e802e6e8e34a491304d7be2f
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Nov 13 19:26:36 2014 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Nov 17 09:36:42 2014 -0500
ExternalProject: Add options to specify BYPRODUCTS (#14963)
The external project's build process may generate byproducts on which
other rules in the driving project's build later depend. Provide a way
for the driving project to specify what byproducts it expects to be made
available by the custom commands that drive the external project.
diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index 32f6d2c..e5616b1 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -132,6 +132,9 @@ Create custom targets to build projects in external trees
Use source dir for build dir
``BUILD_ALWAYS 1``
No stamp file, build step always runs
+ ``BUILD_BYPRODUCTS file...``
+Files that will be generated by the build command but may or may
+not have their modification time updated by subsequent builds.
Install step options are:
@@ -234,6 +237,9 @@ Create custom targets to build projects in external trees
Steps that depend on this step
``DEPENDS file...``
Files on which this step depends
+ ``BYPRODUCTS file...``
+Files that will be generated by this step but may or may not
+have their modification time updated by subsequent builds.
``ALWAYS 1``
No stamp file, step always runs
``EXCLUDE_FROM_MAIN 1``
@@ -1409,6 +1415,9 @@ function(ExternalProject_Add_Step name step)
# Dependencies on files.
get_property(depends TARGET ${name} PROPERTY _EP_${step}_DEPENDS)
+ # Byproducts of the step.
+ get_property(byproducts TARGET ${name} PROPERTY _EP_${step}_BYPRODUCTS)
+
# Dependencies on steps.
get_property(dependees TARGET ${name} PROPERTY _EP_${step}_DEPENDEES)
foreach(dependee IN LISTS dependees)
@@ -1466,6 +1475,7 @@ function(ExternalProject_Add_Step name step)
add_custom_command(
OUTPUT ${stamp_file}
+BYPRODUCTS ${byproducts}
COMMENT ${comment}
COMMAND ${command}
COMMAND ${touch}
@@ -2139,8 +2149,11 @@ function(_ep_add_build_command name)
set(always 0)
endif()
+ get_property(build_byproducts TARGET ${name} PROPERTY _EP_BUILD_BYPRODUCTS)
+
ExternalProject_Add_Step(${name} build
COMMAND ${cmd}
+BYPRODUCTS ${build_byproducts}
WORKING_DIRECTORY ${binary_dir}
DEPENDEES configure
ALWAYS
[Cmake-commits] CMake branch, master, updated. v3.1.0-rc2-255-g545d10c
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 545d10cc6793555ab881d27207e4ae378f3caade (commit) via 474bbb9dbcd6c257e68874e6966c145b3b82dbdd (commit) from d42e3149005eea81458a5104d3053928da395918 (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=545d10cc6793555ab881d27207e4ae378f3caade commit 545d10cc6793555ab881d27207e4ae378f3caade Merge: d42e314 474bbb9 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 17 09:40:44 2014 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 17 09:40:44 2014 -0500 Merge topic 'string-SUBSTRING-truncate' 474bbb9d string: Tolerate SUBSTRING length exceeding end index --- Summary of changes: Help/command/string.rst |7 ++- Source/cmStringCommand.cxx |6 ++ Tests/CMakeTests/StringTest.cmake.in|4 ++-- Tests/CMakeTests/StringTestScript.cmake | 11 +++ 4 files changed, 17 insertions(+), 11 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.1.0-rc2-262-ge943fa8
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 e943fa8a19a1fbe190e6fe0591d2b509e07b9878 (commit)
via f5afb90d7c0ff756dedc3d473c0fb60dee004d82 (commit)
from c61efbd684337bafc6388a3e4daff23492d9992d (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 -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e943fa8a19a1fbe190e6fe0591d2b509e07b9878
commit e943fa8a19a1fbe190e6fe0591d2b509e07b9878
Merge: c61efbd f5afb90
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 17 09:40:51 2014 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Nov 17 09:40:51 2014 -0500
Merge topic 'vs14-is-2015'
f5afb90d VS: Rename VS 14 generator to 'Visual Studio 14 2015'
---
Summary of changes:
...ual Studio 14.rst = Visual Studio 14 2015.rst} | 10 ++---
Help/manual/cmake-generators.7.rst |2 +-
Help/release/3.1.0.rst |2 +-
Source/cmGlobalVisualStudio14Generator.cxx | 40 +++-
Source/cmake.cxx |2 +-
5 files changed, 38 insertions(+), 18 deletions(-)
rename Help/generator/{Visual Studio 14.rst = Visual Studio 14 2015.rst} (66%)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.1.0-rc2-260-gc61efbd
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 c61efbd684337bafc6388a3e4daff23492d9992d (commit) via b138be07b4b2258a3c64245cdf13a4d7cc05b977 (commit) via 8d379cd7ac25481ef3b43da12aade24b1e47ccdf (commit) from ba007d3f07acb18f41d48575ca0b8700cd4a6e8e (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c61efbd684337bafc6388a3e4daff23492d9992d commit c61efbd684337bafc6388a3e4daff23492d9992d Merge: ba007d3 b138be0 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 17 09:40:47 2014 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 17 09:40:47 2014 -0500 Merge topic 'fix-vs2015-warnings' b138be07 cmVisualStudio10TargetGenerator: fix a narrowing warning 8d379cd7 cmCallVisualStudioMacro: fix a shadowing warning --- Summary of changes: Source/cmCallVisualStudioMacro.cxx | 13 +++-- Source/cmVisualStudio10TargetGenerator.cxx |4 ++-- 2 files changed, 9 insertions(+), 8 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.1.0-rc2-681-gffb74d3
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 ffb74d35ace0902289246bb5cd08341effa34cc2 (commit) via afc557d10e8d36db190bab45948f0fa74c8a0a67 (commit) via c5fcbe00afb27fc758e8877efa955e86109a0c67 (commit) from d44666034be9db8cd76a407ef3b1bd58b706ba10 (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ffb74d35ace0902289246bb5cd08341effa34cc2 commit ffb74d35ace0902289246bb5cd08341effa34cc2 Merge: d446660 afc557d Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 17 09:42:17 2014 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 17 09:42:17 2014 -0500 Merge topic 'update-kwsys' into next afc557d1 Merge branch 'upstream-kwsys' into update-kwsys c5fcbe00 KWSys 2014-11-14 (dec9c30b) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=afc557d10e8d36db190bab45948f0fa74c8a0a67 commit afc557d10e8d36db190bab45948f0fa74c8a0a67 Merge: 444f61e c5fcbe0 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 17 09:41:57 2014 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Nov 17 09:41:57 2014 -0500 Merge branch 'upstream-kwsys' into update-kwsys http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c5fcbe00afb27fc758e8877efa955e86109a0c67 commit c5fcbe00afb27fc758e8877efa955e86109a0c67 Author: KWSys Robot kwro...@kitware.com AuthorDate: Fri Nov 14 13:49:32 2014 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Nov 17 09:41:46 2014 -0500 KWSys 2014-11-14 (dec9c30b) Extract upstream KWSys using the following shell commands. $ git archive --prefix=upstream-kwsys/ dec9c30b | tar x $ git shortlog --no-merges --abbrev=8 --format='%h %s' 5843f590..dec9c30b Brad King (1): dec9c30b SharedForward: Hard-code the ldpath buffer size to below VS 14 limit Change-Id: I3430e77f71e68c2eb4f29369080c97afb1613c33 diff --git a/SharedForward.h.in b/SharedForward.h.in index 7ff29b4..c6f345f 100644 --- a/SharedForward.h.in +++ b/SharedForward.h.in @@ -813,7 +813,7 @@ static void kwsys_shared_forward_print_failure(char const* const* argv) } /* Static storage space to store the updated environment variable. */ -static char kwsys_shared_forward_ldpath[KWSYS_SHARED_FORWARD_MAXPATH*16] = KWSYS_SHARED_FORWARD_LDPATH =; +static char kwsys_shared_forward_ldpath[65535] = KWSYS_SHARED_FORWARD_LDPATH =; /*--*/ /* Main driver function to be called from main. */ --- Summary of changes: Source/kwsys/SharedForward.h.in |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.1.0-rc2-275-g85bafee
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 85bafee7eb9a8c9cde16ba5b5099cf33d22d (commit) via afc557d10e8d36db190bab45948f0fa74c8a0a67 (commit) via c5fcbe00afb27fc758e8877efa955e86109a0c67 (commit) from 444f61e044bb2943ccde07e42972d9b2720acd4f (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=85bafee7eb9a8c9cde16ba5b5099cf33d22d commit 85bafee7eb9a8c9cde16ba5b5099cf33d22d Merge: 444f61e afc557d Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 17 09:42:26 2014 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 17 09:42:26 2014 -0500 Merge topic 'update-kwsys' afc557d1 Merge branch 'upstream-kwsys' into update-kwsys c5fcbe00 KWSys 2014-11-14 (dec9c30b) --- Summary of changes: Source/kwsys/SharedForward.h.in |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.1.0-rc2-683-g29cfa91
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 29cfa91316a76e6bd5ab5b55bc2d5608bdfa117c (commit) via 85bafee7eb9a8c9cde16ba5b5099cf33d22d (commit) from ffb74d35ace0902289246bb5cd08341effa34cc2 (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=29cfa91316a76e6bd5ab5b55bc2d5608bdfa117c commit 29cfa91316a76e6bd5ab5b55bc2d5608bdfa117c Merge: ffb74d3 85bafee Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 17 09:42:38 2014 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Nov 17 09:42:38 2014 -0500 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.1.0-rc2-277-g3502231
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 350223141073a91c272d303ee45c0d67e15562d3 (commit) via 480ed9cdec30d59991f6639e79bc5609634a1b47 (commit) from 85bafee7eb9a8c9cde16ba5b5099cf33d22d (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=350223141073a91c272d303ee45c0d67e15562d3 commit 350223141073a91c272d303ee45c0d67e15562d3 Merge: 85bafee 480ed9c Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 17 09:43:32 2014 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 17 09:43:32 2014 -0500 Merge topic 'kwsys-SharedForward-vs14' 480ed9cd KWSys SharedForward: Hard-code the ldpath buffer size to below VS 14 limit --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.1.0-rc2-685-g6c3c6fb
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 6c3c6fba6665be00517b42bd88554f528d83c072 (commit) via 480ed9cdec30d59991f6639e79bc5609634a1b47 (commit) from 29cfa91316a76e6bd5ab5b55bc2d5608bdfa117c (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6c3c6fba6665be00517b42bd88554f528d83c072 commit 6c3c6fba6665be00517b42bd88554f528d83c072 Merge: 29cfa91 480ed9c Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 17 09:43:29 2014 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 17 09:43:29 2014 -0500 Merge topic 'kwsys-SharedForward-vs14' into next 480ed9cd KWSys SharedForward: Hard-code the ldpath buffer size to below VS 14 limit http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=480ed9cdec30d59991f6639e79bc5609634a1b47 commit 480ed9cdec30d59991f6639e79bc5609634a1b47 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Nov 14 13:49:32 2014 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Fri Nov 14 13:56:58 2014 -0500 KWSys SharedForward: Hard-code the ldpath buffer size to below VS 14 limit Visual Studio 14 (2015) complains if a static character array is declared with more than 65535 elements. This limit should be large enough for SharedForward clients, so just hard-code that instead of trying to compute a limit. diff --git a/Source/kwsys/SharedForward.h.in b/Source/kwsys/SharedForward.h.in index 7ff29b4..c6f345f 100644 --- a/Source/kwsys/SharedForward.h.in +++ b/Source/kwsys/SharedForward.h.in @@ -813,7 +813,7 @@ static void kwsys_shared_forward_print_failure(char const* const* argv) } /* Static storage space to store the updated environment variable. */ -static char kwsys_shared_forward_ldpath[KWSYS_SHARED_FORWARD_MAXPATH*16] = KWSYS_SHARED_FORWARD_LDPATH =; +static char kwsys_shared_forward_ldpath[65535] = KWSYS_SHARED_FORWARD_LDPATH =; /*--*/ /* Main driver function to be called from main. */ --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.1.0-rc2-687-g0f0ecd0
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 0f0ecd0c41a70e0ffd82ab7f7d15711162adefd5 (commit) via 350223141073a91c272d303ee45c0d67e15562d3 (commit) from 6c3c6fba6665be00517b42bd88554f528d83c072 (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0f0ecd0c41a70e0ffd82ab7f7d15711162adefd5 commit 0f0ecd0c41a70e0ffd82ab7f7d15711162adefd5 Merge: 6c3c6fb 3502231 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 17 09:43:42 2014 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Nov 17 09:43:42 2014 -0500 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, release, updated. v3.1.0-rc2-12-g598a316
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 598a316154922f27f987d0f7a78b28ab78a85be6 (commit)
via ec34b4b8f732c06b9dd43a401f5513033bd6198d (commit)
via f5afb90d7c0ff756dedc3d473c0fb60dee004d82 (commit)
via 480ed9cdec30d59991f6639e79bc5609634a1b47 (commit)
from 6a16d9c7dfb239bb4a1e2aa44dcfc052f0cab5af (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:
...ual Studio 14.rst = Visual Studio 14 2015.rst} | 10 ++---
Help/manual/cmake-generators.7.rst |2 +-
Help/release/3.1.0.rst |2 +-
Source/cmGlobalVisualStudio14Generator.cxx | 40 +++-
Source/cmake.cxx |2 +-
Source/kwsys/SharedForward.h.in|2 +-
6 files changed, 39 insertions(+), 19 deletions(-)
rename Help/generator/{Visual Studio 14.rst = Visual Studio 14 2015.rst} (66%)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.1.0-rc2-691-gf0771cb
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 f0771cbfc800aa2cba5b25f53eaffac54569a2c7 (commit) via a42c51b5ab54d8d318f00cf9938ce9fb1e2ac274 (commit) via 598a316154922f27f987d0f7a78b28ab78a85be6 (commit) via ec34b4b8f732c06b9dd43a401f5513033bd6198d (commit) from 0f0ecd0c41a70e0ffd82ab7f7d15711162adefd5 (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0771cbfc800aa2cba5b25f53eaffac54569a2c7 commit f0771cbfc800aa2cba5b25f53eaffac54569a2c7 Merge: 0f0ecd0 a42c51b Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 17 09:45:56 2014 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Nov 17 09:45:56 2014 -0500 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.1.0-rc2-280-ga42c51b
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 a42c51b5ab54d8d318f00cf9938ce9fb1e2ac274 (commit) via 598a316154922f27f987d0f7a78b28ab78a85be6 (commit) via ec34b4b8f732c06b9dd43a401f5513033bd6198d (commit) from 350223141073a91c272d303ee45c0d67e15562d3 (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: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.1.0-rc2-695-g9c77dc2
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 9c77dc227a7b1505dada93ad9fba777fabc08f8f (commit)
via d931ba60216dfcb5f94ffc3b8e6d977b1e4dc22f (commit)
from 7c767fe68dc8270f2e84f59071fc6562734198c7 (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 -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9c77dc227a7b1505dada93ad9fba777fabc08f8f
commit 9c77dc227a7b1505dada93ad9fba777fabc08f8f
Merge: 7c767fe d931ba6
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 17 10:35:04 2014 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Nov 17 10:35:04 2014 -0500
Merge topic 'FindCurses-no-cur_colr' into next
d931ba60 FindCurses: Drop search for deprecated HP-UX cur_colr library
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d931ba60216dfcb5f94ffc3b8e6d977b1e4dc22f
commit d931ba60216dfcb5f94ffc3b8e6d977b1e4dc22f
Author: Ådne Hovda aho...@openit.com
AuthorDate: Mon Nov 17 12:11:55 2014 +0100
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Nov 17 10:32:52 2014 -0500
FindCurses: Drop search for deprecated HP-UX cur_colr library
Since commit b22e2de8 (HPUX support, 2001-11-05) the FindCurses
module searches for a 'cur_colr' library, but that is not needed
anymore. AFAICT, the cur_colr package was introduced in HP-UX 10.00 and
marked as deprecated in 10.30 by X/OPEN curses (which replaced the even
older HP curses in 10.10).
In order to use cur_colr after 10.10 you should use the
/usr/include/curses_colr when compiling. Since FindCurses doesn't even
search that path the headers cannot possibly match out of the box. If
users want cur_colr they can set the cache entries by hand.
There is no 64-bit version of cur_colr in 11.11PA and it will be gone
completely in 11.31PA:
http://h21007.www2.hp.com/portal/download/files/unprot/STK/HPUX_STK/impacts/i964.html
It is simplest to drop cur_colr support from FindCurses since it was
only partially implemented anyway.
diff --git a/Modules/FindCurses.cmake b/Modules/FindCurses.cmake
index 0184c39..c628ab0 100644
--- a/Modules/FindCurses.cmake
+++ b/Modules/FindCurses.cmake
@@ -178,11 +178,6 @@ if(NOT DEFINED CURSES_HAVE_CURSES_H)
endif()
endif()
-if (NOT CURSES_TINFO_HAS_CBREAK)
- find_library(CURSES_EXTRA_LIBRARY cur_colr HINTS ${_cursesLibDir})
- find_library(CURSES_EXTRA_LIBRARY cur_colr )
-endif()
-
find_library(CURSES_FORM_LIBRARY form HINTS ${_cursesLibDir})
find_library(CURSES_FORM_LIBRARY form )
---
Summary of changes:
Modules/FindCurses.cmake |5 -
1 file changed, 5 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.1.0-rc2-701-gf889ba2
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 f889ba21a6d4688ebeff8cf36e4cd6f9f83f7a26 (commit) via d903f7ce910879ad5439d642488e508aafd4b049 (commit) from 33bc5a0860a8e488f7efe6a891ce8e5161d9ac6f (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f889ba21a6d4688ebeff8cf36e4cd6f9f83f7a26 commit f889ba21a6d4688ebeff8cf36e4cd6f9f83f7a26 Merge: 33bc5a0 d903f7c Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 17 15:16:07 2014 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Nov 17 15:16:07 2014 -0500 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.1.0-rc2-286-gd903f7c
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 d903f7ce910879ad5439d642488e508aafd4b049 (commit) via 1d22ee67aafc2fce51b469fd600a053b9a6e2bc4 (commit) from 3609fceee75b4f3751a702ac0a7f21e5cbd67a0a (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d903f7ce910879ad5439d642488e508aafd4b049 commit d903f7ce910879ad5439d642488e508aafd4b049 Merge: 3609fce 1d22ee6 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 17 15:15:56 2014 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 17 15:15:56 2014 -0500 Merge topic 'doc-target_include_directories-fixup' 1d22ee67 Help: target_include_directories does not allow target names --- Summary of changes: Help/command/target_include_directories.rst |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.1.0-rc2-703-g03519a5
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 03519a582873578b18afefa74b71a6bab6e4ea02 (commit)
via 5cda220548b82010b9f2fc9f177e808b6151a162 (commit)
from f889ba21a6d4688ebeff8cf36e4cd6f9f83f7a26 (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 -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=03519a582873578b18afefa74b71a6bab6e4ea02
commit 03519a582873578b18afefa74b71a6bab6e4ea02
Merge: f889ba2 5cda220
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 17 15:38:43 2014 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Nov 17 15:38:43 2014 -0500
Merge topic 'doc-sphinx-cmake-fixup' into next
5cda2205 Utilities/Sphinx: Add missing call to note_explicit_target
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5cda220548b82010b9f2fc9f177e808b6151a162
commit 5cda220548b82010b9f2fc9f177e808b6151a162
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 17 15:34:55 2014 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Nov 17 15:37:31 2014 -0500
Utilities/Sphinx: Add missing call to note_explicit_target
Sphinx calls document.note_explicit_target with any nodes.target() it
creates. Add such a call when we create a document target in
CMakeTransform.
diff --git a/Utilities/Sphinx/cmake.py b/Utilities/Sphinx/cmake.py
index ec39596..e20679a 100644
--- a/Utilities/Sphinx/cmake.py
+++ b/Utilities/Sphinx/cmake.py
@@ -203,6 +203,7 @@ class CMakeTransform(Transform):
# Insert the object link target.
targetid = '%s:%s' % (objtype, title)
targetnode = nodes.target('', '', ids=[targetid])
+self.document.note_explicit_target(targetnode)
self.document.insert(0, targetnode)
# Insert the object index entry.
indexnode = addnodes.index()
---
Summary of changes:
Utilities/Sphinx/cmake.py |1 +
1 file changed, 1 insertion(+)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.1.0-rc2-287-g52fd577
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 52fd5775d1e90cc5beff0fbd6c9751caecd5833a (commit) from d903f7ce910879ad5439d642488e508aafd4b049 (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=52fd5775d1e90cc5beff0fbd6c9751caecd5833a commit 52fd5775d1e90cc5beff0fbd6c9751caecd5833a Author: Kitware Robot kwro...@kitware.com AuthorDate: Tue Nov 18 00:01:08 2014 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Tue Nov 18 00:01:08 2014 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index ab05c2a..09284d2 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 1) -set(CMake_VERSION_PATCH 20141117) +set(CMake_VERSION_PATCH 20141118) #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 http://public.kitware.com/mailman/listinfo/cmake-commits
