Re: [cmake-developers] suggestion: rename FindXerces to FindXercesC
The patch worked for me. cheers, Erik Sjölund On Thu, Dec 4, 2014 at 4:52 PM, Brad King brad.k...@kitware.com wrote: On 12/04/2014 10:32 AM, Brad King wrote: Roger, as the contributor of this module do you have any reason not to change the name? I've constructed a commit to perform the rename and merged to 'next' for testing: Modules: Rename FindXerces to FindXercesC http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27141eed Please let me know if it works. I'd like to get feedback before merging to 'master' or 'release'. 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] suggestion: rename FindXerces to FindXercesC
On 12/04/2014 05:54 PM, Roger Leigh wrote: No. Either is fine with me; I didn't expect this to be problematic to omit the C suffix, but happy to have it added if it will avoid confusion. I just saw your other mail saying you'd made a patch. Do you need me to do anything else? Please just test the renamed module to verify it still works for your original use case (besides the name change). With Erik's confirmation I will merge this for the next 3.1 release candidate anyway, but more testing is better ;) 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] New command 'file(LOCK_DIRECTORY ...)'
On 05-Dec-14 17:12, Brad King wrote: On 12/05/2014 09:10 AM, Ruslan Baratov wrote: file: Add LOCK subcommand to do file and directory locking http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e6db4c5a Great, thank you! So will this be applied to cmake 3.1.0? No, sorry. The feature deadline for that was almost 2 months ago. The release candidate period has been pretty drawn out this time :( -Brad Okay, just curious what version it will be? Ruslo -- 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 12/05/2014 09:38 AM, Ruslan Baratov wrote: Okay, just curious what version it will be? 3.2. There is a roadmap here: http://www.cmake.org/Bug/roadmap_page.php with tentative dates. -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] New command 'file(LOCK_DIRECTORY ...)'
On 05-Dec-14 17:09, Brad King wrote:
On 12/05/2014 09:03 AM, Ruslan Baratov wrote:
Actually why not use 'strtoll' and 'long long' ?
I'm not sure that function or type exists portably on some of the
older host platforms we support. The long type should be plenty
big for timeout values, and there are other strtol call sites that
already use long and could be converted to use a StringToLong
helper too.
Sending patch with 'long'.
Actually for the lock timeout use case would it make sense to change
to a floating point value so timeouts can be more granular? Some
use cases may not want to block for a whole second between lock
attempts.
What granularity you think is appropriate, 100 ms? 10 ms? (It will be
value in `cmSystemTools::Delay(...);`)
Ruslo
From 3ed0ad891c6108fa2a03834f9fe109ee5d628847 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Fri, 5 Dec 2014 17:18:11 +0300
Subject: [PATCH] Use 'long' for StringToInt
---
Source/cmFileCommand.cxx | 6 +++---
Source/cmFileLock.cxx | 4 ++--
Source/cmFileLock.h| 4 ++--
Source/cmFileLockPool.cxx | 8
Source/cmFileLockPool.h| 10 ++
Source/cmFileLockUnix.cxx | 2 +-
Source/cmFileLockWin32.cxx | 2 +-
Source/cmSystemTools.cxx | 7 ---
Source/cmSystemTools.h | 4 ++--
9 files changed, 25 insertions(+), 22 deletions(-)
diff --git a/Source/cmFileCommand.cxx b/Source/cmFileCommand.cxx
index a6eb8c4..42cd132 100644
--- a/Source/cmFileCommand.cxx
+++ b/Source/cmFileCommand.cxx
@@ -3521,7 +3521,7 @@ bool cmFileCommand::HandleLockCommand(
};
Guard guard = GUARD_PROCESS;
std::string resultVariable;
- unsigned timeout = static_castunsigned(-1);
+ unsigned long timeout = static_castunsigned long(-1);
// Parse arguments
if(args.size() 2)
@@ -3597,7 +3597,7 @@ bool cmFileCommand::HandleLockCommand(
expected timeout value after TIMEOUT);
return false;
}
- int scanned;
+ long scanned;
if(!cmSystemTools::StringToInt(args[i].c_str(), scanned) || scanned 0)
{
cmOStringStream e;
@@ -3605,7 +3605,7 @@ bool cmFileCommand::HandleLockCommand(
this-Makefile-IssueMessage(cmake::FATAL_ERROR, e.str());
return false;
}
- timeout = static_castunsigned(scanned);
+ timeout = static_castunsigned long(scanned);
}
else
{
diff --git a/Source/cmFileLock.cxx b/Source/cmFileLock.cxx
index 5f75637..e6aa5f4 100644
--- a/Source/cmFileLock.cxx
+++ b/Source/cmFileLock.cxx
@@ -28,7 +28,7 @@ cmFileLock::~cmFileLock()
}
cmFileLockResult cmFileLock::Lock(
-const std::string filename, unsigned timeout)
+const std::string filename, unsigned long timeout)
{
if (filename.empty())
{
@@ -48,7 +48,7 @@ cmFileLockResult cmFileLock::Lock(
cmFileLockResult result = this-OpenFile();
if (result.IsOk())
{
-if (timeout == static_castunsigned(-1))
+if (timeout == static_castunsigned long(-1))
{
result = this-LockWithoutTimeout();
}
diff --git a/Source/cmFileLock.h b/Source/cmFileLock.h
index 4d922a0..dd959a7 100644
--- a/Source/cmFileLock.h
+++ b/Source/cmFileLock.h
@@ -37,7 +37,7 @@ class cmFileLock
* @brief Lock the file.
* @param timeoutSec Lock timeout. If -1 try until success or fatal error.
*/
- cmFileLockResult Lock(const std::string filename, unsigned timeoutSec);
+ cmFileLockResult Lock(const std::string filename, unsigned long timeoutSec);
/**
* @brief Unlock the file.
@@ -57,7 +57,7 @@ class cmFileLock
cmFileLockResult OpenFile();
cmFileLockResult LockWithoutTimeout();
- cmFileLockResult LockWithTimeout(unsigned timeoutSec);
+ cmFileLockResult LockWithTimeout(unsigned long timeoutSec);
#if defined(_WIN32)
typedef HANDLE FileId;
diff --git a/Source/cmFileLockPool.cxx b/Source/cmFileLockPool.cxx
index e84e71a..551a75a 100644
--- a/Source/cmFileLockPool.cxx
+++ b/Source/cmFileLockPool.cxx
@@ -60,7 +60,7 @@ void cmFileLockPool::PopFileScope()
}
cmFileLockResult cmFileLockPool::LockFunctionScope(
-const std::string filename, unsigned timeoutSec)
+const std::string filename, unsigned long timeoutSec)
{
if (this-IsAlreadyLocked(filename))
{
@@ -74,7 +74,7 @@ cmFileLockResult cmFileLockPool::LockFunctionScope(
}
cmFileLockResult cmFileLockPool::LockFileScope(
-const std::string filename, unsigned timeoutSec)
+const std::string filename, unsigned long timeoutSec)
{
if (this-IsAlreadyLocked(filename))
{
@@ -85,7 +85,7 @@ cmFileLockResult cmFileLockPool::LockFileScope(
}
cmFileLockResult cmFileLockPool::LockProcessScope(
-const std::string filename, unsigned timeoutSec)
+const std::string filename, unsigned long timeoutSec)
{
if (this-IsAlreadyLocked(filename))
{
@@ -155,7 +155,7 @@ cmFileLockPool::ScopePool::~ScopePool()
}
cmFileLockResult cmFileLockPool::ScopePool::Lock(
-const std::string filename, unsigned
Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'
On 12/05/2014 09:51 AM, Ruslan Baratov wrote: Sending patch with 'long'. Applied while also renaming to StringToLong, thanks: file: Use 'long' to represent the parsed LOCK TIMEOUT value http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=97841dad What granularity you think is appropriate, 100 ms? 10 ms? (It will be value in `cmSystemTools::Delay(...);`) On second thought, it is easy to change this later if a case comes up that really needs it, so let's stay with 1s for now. 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] Which binaries should be required in FindLATEX?
Hi Christoph, Thanks for working on this. On 12/05/2014 02:35 AM, Christoph Grüninger wrote: For users it would be great to simply have all these binaries. I don't have all the converters installed but can still build PDF books. The varying tools do not all come in the same package on Linux distros. Of course most projects will want most or all of the tools. For this I think the FindLATEX module should implement support for the find_package COMPONENTS option. Then projects can specify what they need: find_package(LATEX COMPONENTS latex pdflatex bibtex ...) and the module will compute the proper LATEX_FOUND value based on the availability of all the requested components. If this is still to restrictive, I propose to only test for the LaTeX compiler and let the user check for the other binaries (with if(MAKEINDEX_COMPILER) ) With proper component support I think that proposal makes sense. If no components are listed then LATEX_FOUND should be based only on LATEX_COMPILER. If components are listed then all of them must be found. Of course this approach can be implemented first to get FPHSA working and component support added later. Any components listed would just be added to the list given to the REQUIRED_VARS option of FPHSA. In any case, I'll have to clarify this in the documentation for my next patch. In the next revision please also add your name to the author field instead of the Github user id. 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] [DISCUSSION] Using COMPONENTs for CMake install(...)?
On 12/04/2014 12:59 AM, Konstantin Podsvirov wrote: In the source tree, you can see some of the components. The Debian packaging can serve as a good reference: cmake - cross-platform, open-source make system cmake-curses-gui - curses based user interface for CMake (ccmake) cmake-data - CMake data files (modules, templates and documentation) cmake-doc - extended documentation in various formats for CMake cmake-qt-gui - Qt4 based user interface for CMake (cmake-gui) For example: -- tools - cmake - cpack - ctest Yes. -- scripts - modules - templates These are the Debian cmake-data package. -- documentation - manual * html version * man pages Debian packages the tool man pages with the tools due to their policy of having documentation available for all commands. Other manuals are in the separate cmake-doc package. For interactive installers I think we can keep all the docs in their own packages separate from the tools since the doc format could be made selectable. The html and man pages could be placed in separate install components too. -- according to - Qt (only necessary) Separate components for each of the ccmake and cmake-gui interactive dialogs makes sense. With the above guidance please go ahead and work on the patch if you want. All the install() calls will need to be updated with the proper COMPONENT option(s). Also I suggest to add in CMakeLists.txt option to control the installation of dependencies with CMake. For example the Qt library. This happens on Windows and Mac, but I think it is not always necessary in Linux. This is a separate task, so let's focus on the components first. -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] why does the order of the options in file(GENERATE) matter?
I see, thanks. cheers, Erik Sjölund On Fri, Dec 5, 2014 at 7:32 PM, Brad King brad.k...@kitware.com wrote: On 12/05/2014 04:28 AM, Erik Sjölund wrote: The CMake documentation doesn't mention that the order matters: http://www.cmake.org/cmake/help/v3.1/command/file.html#command:file Why does the order of the options in file(GENERATE) matter? It was always implemented that way: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFileCommand.cxx;hb=v3.1.0-rc2#l3421 but the order was dropped from the documentation by accident during reformatting. I've fixed the documentation: Help: Document file(GENERATE) signature option order http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe21580b -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] [DISCUSSION] Using COMPONENTs for CMake install(...)?
Hi, Brad! 05.12.2014, 22:33, Brad King brad.k...@kitware.com: On 12/04/2014 12:59 AM, Konstantin Podsvirov wrote: In the source tree, you can see some of the components. The Debian packaging can serve as a good reference: cmake - cross-platform, open-source make system cmake-curses-gui - curses based user interface for CMake (ccmake) cmake-data CMake data files (modules, templates and documentation) cmake-doc - extended documentation in various formats for CMake cmake-qt-gui - Qt4 based user interface for CMake (cmake-gui) I agree. My way of studying operating systems started with Windows and I spend a lot of time here. Then I was introduced to Linux and chose Debian. For example: -- tools - cmake - cpack - ctest Yes. -- scripts - modules - templates These are the Debian cmake-data package. -- documentation - manual * html version * man pages Debian packages the tool man pages with the tools due to their policy of having documentation available for all commands. Other manuals are in the separate cmake-doc package. For interactive installers I think we can keep all the docs in their own separate packages from the tools since the doc format could be made selectable. It is understandable. The html and man pages could be placed in separate install components too. -- according to - Qt (only necessary) Separate components for each of the ccmake and cmake-gui interactive dialogs makes sense. With the above guidance please go ahead and work on the patch if you want. All the install() calls will need to be updated with the proper COMPONENT option(s). I am interested this task. Perhaps I will start working on my server in a separate branch. I will try to create a graphical installers using CPack IFW generator. At first I plan to submit for debugging and testing the compiled version in Debian stable, and Windows 7. Unfortunately I have no way to test this for Mac. :-( Brad what desktop do you use? Also I suggest to add in CMakeLists.txt option to control the installation of dependencies with CMake For example the Qt library. This happens on Windows and Mac but I think it is not always necessary in Linux. This is a separate task, so let's focus on the components first. -Brad Well. A separate task separate from the main :-) Thank you for writing this letter. I was waiting for him. Regards, Konstantin Podsvirov -- 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
