[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
