On 2014-10-13 10:39, Brad King wrote:
On 10/10/2014 07:45 AM, Ruslan Baratov wrote:
Locking directory is equivalent to locking file `cmake.lock` in
directory /path/to/shared/directory/:
I think this can be activated buy a DIRECTORY option.
Why do we need even that? Can't CMake just test if
On 17-Dec-14 21:11, Matthew Woehlke wrote:
On 2014-10-13 10:39, Brad King wrote:
On 10/10/2014 07:45 AM, Ruslan Baratov wrote:
Locking directory is equivalent to locking file `cmake.lock` in
directory /path/to/shared/directory/:
I think this can be activated buy a DIRECTORY option.
Why do we
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
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:
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
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,
On 12/01/2014 10:52 AM, Brad King wrote:
cmSystemTools: Add StringToInt helper
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5121f118
file: Add LOCK subcommand to do file and directory locking
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fca624ca
Help: Add notes for topic
On 12/01/2014 10:52 AM, Brad King wrote:
Thanks. I squashed the commits since the addition of the files
cannot be tested independently, made minor tweaks, and merged
to 'next' for testing:
Testing went pretty well, but the RunCMake.file test fails on HP-UX
in the LOCK-error-timeout case:
On 12/02/2014 10:03 AM, Brad King wrote:
Testing went pretty well, but the RunCMake.file test fails on HP-UX
in the LOCK-error-timeout case:
http://open.cdash.org/testDetails.php?test=297595272build=3594885
The relevant expect/actual lines are:
expect-err Timeout reached\.
On 11/25/2014 06:24 PM, Ruslan Baratov wrote:
updated
Thanks. I squashed the commits since the addition of the files
cannot be tested independently, made minor tweaks, and merged
to 'next' for testing:
cmSystemTools: Add StringToInt helper
Rolf Eike Beer wrote:
Brad King wrote:
On 12/01/2014 11:05 AM, Rolf Eike Beer wrote:
+ char *endp;
+ *value = static_castint(strtol(str, endp, 10));
+ return (*endp == '\0') (endp != str);
Fine with me. Please extend the topic accordingly. I will squash
it in later.
Done.
On 12/01/2014 03:26 PM, Stephen Kelly wrote:
Existing uses of strtol also check errno. I guess your implementation should
too.
Yes, IIUC it is a range check on whether the value can be represented.
Then the existing users should use this new method.
In that case the type should be changed
On 11/17/2014 06:45 PM, Ruslan Baratov wrote:
Done
Thanks. Here are some more comments:
* Please rebase on current 'master' to resolve conflicts.
* The background.(bat|sh) files need to have quoting to work with
spaces in the path. Please try running tests with a source/build
tree with
On 25-Nov-14 21:29, Brad King wrote:
* The background.(bat|sh) files need to have quoting to work with
spaces in the path. Please try running tests with a source/build
tree with spaces.
* Instead of background scripts, can you have a parent process take
a lock, run a child with a
On 11/17/2014 6:45 PM, Ruslan Baratov wrote:
Done
Thanks for the updates. I'll try this out again when
I get a chance.
-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
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
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
Am Samstag, 15. November 2014, 02:27:40 schrieb Ruslan Baratov via cmake-
developers:
On 14-Nov-14 22:58, Brad King wrote:
- Please add more test cases covering all the file(LOCK)
argument processing error messages.
Done. Also I've found parse issue which is based on `sscanf`
ConvertToWindowsExtendedPath fix + tests
From e994378d61e64136043d9db614762e79927766cb Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Fri, 14 Nov 2014 21:09:35 +0400
Subject: [PATCH 1/6] Add class cmFileLockResult
---
Source/cmFileLockResult.cxx | 111
On 11/14/2014 12:31 PM, Ruslan Baratov wrote:
ConvertToWindowsExtendedPath fix + tests
Thanks. I started testing on Linux so far. A few more comments:
- Please add more test cases covering all the file(LOCK)
argument processing error messages.
- Please squash in the attached patch to your
On 14-Nov-14 22:58, Brad King wrote:
- Please add more test cases covering all the file(LOCK)
argument processing error messages.
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
On 11-Nov-14 21:28, Brad King wrote:
* All headers and sources need to include cmStandardIncludes.h first,
directly or indirectly through other headers. It can affect the
way certain standard library headers are preprocessed on some
platforms, and needs to be consistent across all
On 11/13/2014 09:01 AM, Ruslan Baratov wrote:
* Please add documentation to Help/command/file.rst and anywhere else
that is appropriate.
Done
Thanks. I will try out the patch when I get a chance to provide further
feedback.
Is it possible to run tests only from 'Tests/RunCMake/file'
Done
On 31-Oct-14 16:39, Brad King wrote:
On 10/31/2014 09:07 AM, Ruslan Baratov wrote:
Does anybody ready to implement it or you want me to send the patches?
Please work on the patches. You can use git format-patch to format
them and post here either inline or as attachments.
Thanks,
-Brad
Does anybody ready to implement it or you want me to send the patches?
Ruslo
On 29-Oct-14 16:48, Brad King wrote:
On 10/28/2014 04:28 PM, Ruslan Baratov wrote:
What do you think about this:
Thanks for drafting the signature.
file(
LOCK path
[DIRECTORY] # if present locked file
On 10/31/2014 09:07 AM, Ruslan Baratov wrote:
Does anybody ready to implement it or you want me to send the patches?
Please work on the patches. You can use git format-patch to format
them and post here either inline or as attachments.
Thanks,
-Brad
--
Powered by www.kitware.com
Please
On 10/28/2014 04:28 PM, Ruslan Baratov wrote:
What do you think about this:
Thanks for drafting the signature.
file(
LOCK path
[DIRECTORY] # if present locked file will be path/cmake.lock
(instead of path)
[RELEASE] # do explicit unlock
[GUARD FUNCTION|FILE|PROCESS] #
On 13-Oct-14 18:39, Brad King wrote:
With all the above in mind, please brainstorm and propose a more complete
signature set. You can use the keyword/value pairing common in other
commands to avoid needing a positional argument for every value.
What do you think about this:
file(
LOCK
On Fri, Oct 10, 2014 at 17:59:07 +0400, Ruslan Baratov via cmake-developers
wrote:
Behavior when there's a lock that still exists (by bug/mistake) after
CMake is done running is going to be strange and possibly
hard-to-diagnose / hard-to-understand.
That's *exactly* the problem I have and
On 10/10/2014 07:45 AM, Ruslan Baratov wrote:
file(TRY_LOCK /path/to/file result) # try to lock and return TRUE on
success (needed?)
file(LOCK ...) # lock until unlock (unlock by further code (what if
exit/crashed?) or by deamon)
The LOCK signature should have a timeout after which it
On 10/13/2014 10:34 AM, Ben Boeckel wrote:
Maybe we need something like the 'trap' shell builtin which runs code on
various triggers
That would first require an 'eval' equivalent in CMake, e.g. cmake_eval().
This has been requested a few times.
-Brad
--
Powered by www.kitware.com
Please
On 08-Oct-14 16:45, Brad King wrote:
On 10/08/2014 07:52 AM, Ruslan Baratov wrote:
Okay :) I just not sure that I understand to pass to some other
process goal correctly.
That was just an example of why one might want to drop management
of the lock by CMake without actually unlocking it.
What is the main use case for locking files and directories from the
CMake language?
I feel slightly uncomfortable, without being able to put my finger on
exactly why, with the prospect of adding this to CMake...
Behavior when there's a lock that still exists (by bug/mistake) after
CMake is done
On 10-Oct-14 16:58, David Cole wrote:
What is the main use case for locking files and directories from the
CMake language?
I feel slightly uncomfortable, without being able to put my finger on
exactly why, with the prospect of adding this to CMake...
I've described the situation in the first
On 07-Oct-14 16:25, Brad King wrote:
On 10/07/2014 02:49 AM, Ruslan Baratov wrote:
How it will looks like in terms of CMake code?
That's what I'm asking you to think through and propose ;)
Thanks,
-Brad
Okay :) I just not sure that I understand to pass to some other
process goal correctly.
On 10/08/2014 07:52 AM, Ruslan Baratov wrote:
Okay :) I just not sure that I understand to pass to some other
process goal correctly.
That was just an example of why one might want to drop management
of the lock by CMake without actually unlocking it. Perhaps the
code is starting a daemon and
On 06-Oct-14 16:54, Brad King wrote:
On 10/05/2014 04:59 PM, Ruslan Baratov via cmake-developers wrote:
So it can't be resolved without some low-level management. I'm thinking
about `file` command sub-option like LOCK_DIRECTORY:
`file(LOCK_DIRECTORY /path/to/shared-dir)`. Does it sounds doable?
On 10/07/2014 02:49 AM, Ruslan Baratov wrote:
How it will looks like in terms of CMake code?
That's what I'm asking you to think through and propose ;)
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
On 10/05/2014 04:59 PM, Ruslan Baratov via cmake-developers wrote:
So it can't be resolved without some low-level management. I'm thinking
about `file` command sub-option like LOCK_DIRECTORY:
`file(LOCK_DIRECTORY /path/to/shared-dir)`. Does it sounds doable?
I think it is a reasonable
Hi,
I have CMake modules that can share resources between different
instances. For now I manage it by invoking `mkdir
shared-dir/lock-directory` and checking the result, then removing this
directory so the next instance can do the modification. The problem
occurs when somebody terminate
40 matches
Mail list logo
