Re: [cmake-developers] cmake-gui icons

2014-10-31 Thread Orion Poplawski 
On 10/29/2014 09:50 AM, Ben Boeckel wrote:
> On Mon, Oct 27, 2014 at 11:59:09 -0600, Orion Poplawski wrote:
>> Fedora is pushing to have higher resolution icons for the applications. There
>> already is CMakeSetup128.png, but these would need to get installed into the
>> proper /usr/share/icons/ hierarchy and named appropriately for the correct
>> size to be automatically found and used. It would be good to have cmake-gui 
>> be
>> conformant to the current desktop standards.
> 
> The 128x128 is now installed with the branch currently on stage (and
> next):
> 
> unix-icon-install
> 

Looks good. You might want to add more resolutions, maybe a svg version too.
According to https://bugzilla.redhat.com/show_bug.cgi?id=1157509, the
recommended sizes are 24x24, 48x48, 64x64 and 256x256

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
-- 

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] Please review patch for 'continue' keyword

2014-10-31 Thread Gregor Jasny 
Hello,

I use CMake extensively for cross platform and sometimes I write really
complex functions. Sometimes I wish we had a 'continue' keyword to keep
loops readable. There is a wishlist report about that and Doug Barbieri
even added a patch:

http://www.cmake.org/Bug/view.php?id=14013

I re-applied the patch to master, fixed some bit-rot and formatted it
via git format-patch (also attached). Could you please take a look? It
would be great if the 'continue' keyword support would be part of CMake
3.2.

Thanks,
Gregor

PS: I'm unable to see Doug Barbieri email address in Mantis, so I cannot
properly attribute him as original patch author.
From 55dd89a8105e5576b1f6a3c0fde7ed7ffc8418ed Mon Sep 17 00:00:00 2001
From: Gregor Jasny 
Date: Thu, 23 Oct 2014 09:28:55 +0200
Subject: [PATCH] Add continue keyword (#14013)

Original patch by Doug Barbieri.

Signed-off-by: Gregor Jasny 
---
 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 +++
 8 files changed, 105 insertions(+)
 create mode 100644 Help/command/continue.rst
 create mode 100644 Source/cmContinueCommand.cxx
 create mode 100644 Source/cmContinueCommand.h

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 9093579..d129aef 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"
@@ -68,6 +69,7 @@ void GetBootstrapCommands1(std::list& 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..ecb894b
--- /dev/null
+++ b/Source/cmContinueCommand.cxx
@@ -0,0 +1,21 @@
+/*
+  CMake - Cross Platform Makefile Generator
+  Copyright 2000-2009 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::vector const&,
+  cmExecutionStatus &status)
+{
+  status.SetContinueInvoked(true);
+  return true;
+}
+
diff --git a/Source/cmContinueCommand.h b/Source/cmContinueCommand.h
new file mode 100644
index 000..2107637
--- /dev/null
+++ b/Source/cmContinueCommand.h
@@ -0,0 +1,55 @@
+/*
+  CMake - Cross Platform Makefile Generator
+  Copyright 2000-2009 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"
+
+/** \class cmContinueCommand
+ * \brief Continue from an enclosing foreach or while loop
+ *
+ * cmContinueCommand returns from an enclosing foreach or while loop
+ */
+class cmContinueCommand : public cmCommand
+{
+public:
+  /**
+   * This is a virtual constructor for the command.
+   */
+  virtual cmCommand* Clone()
+{
+return new cmContinueCommand;
+}
+
+  /**
+   * This is called when the

Re: [cmake-developers] Help enabling libssh2 in cmake

2014-10-31 Thread Brad King 
On 10/31/2014 01:25 PM, Jameson Merkow wrote:
> Thanks Brad! Its working with my system curl! 

Great!

> Shall I wait till you complete re-adding curl into the cmake build to submit?

If you don't mind, yes.  I'd prefer not to make further modifications to
the current version of curl in CMake because they will just be more
conflicts for updating it.  If it doesn't happen in the next few weeks
please ping again.

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] Help enabling libssh2 in cmake

2014-10-31 Thread Jameson Merkow 
Thanks Brad! Its working with my system curl!
Here is the curl version I am using.
curl 7.38.1-DEV (Linux) libcurl/7.38.1-DEV OpenSSL/1.0.1f zlib/1.2.8
libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s
rtsp scp sftp smtp smtps telnet tftp
Features: IDN IPv6 NTLM SSL libz

What are the next steps?  Shall I wait till you complete re-adding curl
into the cmake build to submit? I could prevent users from using
CMAKE_USE_LIBSSH2=1 and CMAKE_USE_SYSTEM_CURL=0.  Or I could submit it as
is (after I clean out the debug messages).  I had been talking to Bill
Hoffman (on the users mailing list) about adding libssh2 support for
upcoming binaries, so I guess it depends on your build settings for the
binaries too...

-Jameson

On Thu, Oct 30, 2014 at 7:30 AM, Brad King  wrote:

> On 10/29/2014 04:27 PM, Jameson Merkow wrote:
> > I am working on adding libssh2 support into cmake
>
> Great!
>
> > change for libssh2_free to libssh2_free2 in ssh.c
>
> Try building against a system-installed curl by enabling
> CMAKE_USE_SYSTEM_CURL.  That should be much more recent
> than the version that comes in CMake and may have fixed
> some problems.
>
> I have been working slowly toward updating the version
> of curl that comes in our source tree but it is not ready
> yet.
>
> -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 0015231]: find_package: should be a simple way to alter the order of the config/module lookups

2014-10-31 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15231 
== 
Reported By:Charles Karney
Assigned To:
== 
Project:CMake
Issue ID:   15231
Category:   CMake
Reproducibility:N/A
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2014-10-31 12:31 EDT
Last Modified:  2014-10-31 12:31 EDT
== 
Summary:find_package: should be a simple way to alter the
order of the config/module lookups
Description: 
As we are integrating cmake more and more into our environment, it is
clear how much superior the config-mode for find_package is compared to
the module-mode.  As a result, our top-level CMakeLists.txt contains
several occurrences of the following pattern

  find_package (PROJ4 CONFIG QUIET)
  if (NOT PROJ4_FOUND)
find_package (PROJ4 MODULE REQUIRED)
  endif ()

Request 1: Add

  MODULE_FIRST
  CONFIG_FIRST

options to find_package, meaning do the module lookup first (the default
but see next) or the config lookup first.  (These options complement the
MODULE and CONFIG options.)  So the find_package invocation above
becomes

  find_package (PROJ4 CONFIG_FIRST REQUIRED)

Request 2: Add a global variable, e.g., CMAKE_FIND_PACKAGE_PREFER_CONFIG
(default OFF) to specify the default lookup order.  Thus if I've worked
to get all my dependent packages with config-mode support, I can invoke
cmake with

  cmake -DCMAKE_FIND_PACKAGE_PREFER_CONFIG=ON ..

without having to edit the CMakeLists.txt file.

Finally a comment: the advice (not sure where from) that our current
pattern can be shortened to

  find_package (PROJ4 NO_MODULE QUIET)
  find_package (PROJ4 MODULE)

seems not to hold in all cases.  If you think this should work, let me
know and I will look for a counter-example.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2014-10-31 12:31 Charles Karney 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] [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

2014-10-31 Thread Gilles Khouzam 
We actually have a couple if extra changes that are not fully ready to be 
pushed upstream yet.

~Gilles
Sent from my Windows Phone

From: Brad King
Sent: ‎10/‎31/‎2014 8:26
To: Eric Wing
Cc: Robert Maynard; CMake 
Developers; CMake 
MailingList; Gilles 
Khouzam
Subject: Re: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready 
for testing!

On 10/30/2014 07:19 PM, Eric Wing wrote:
> Just curious, are the new WinRT changes the same exact changes from CMakeMS?

Yes.  After prototyping the changes in CMakeMS they worked with us
to contribute the functionality upstream.

-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 0015230]: Behavior of relative paths of target properties

2014-10-31 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15230 
== 
Reported By:Lekensteyn
Assigned To:
== 
Project:CMake
Issue ID:   15230
Category:   Documentation
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2014-10-31 12:06 EDT
Last Modified:  2014-10-31 12:06 EDT
== 
Summary:Behavior of relative paths of target properties
Description: 
I was wondering whether relative paths can be used in the
LIBRARY_OUTPUT_DIRECTORY property, but this is not documented. @ngladitz
confirmed on IRC that paths are resolved against the binary directory, referring
to the code[1].

Affected documentation:
http://www.cmake.org/cmake/help/v3.0/command/add_library.html
http://www.cmake.org/cmake/help/v3.0/prop_tgt/LIBRARY_OUTPUT_DIRECTORY.html
...

 [1]:
http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;h=ee62f060607c8fa95da2118784e089bcd70a23fe;hb=HEAD#l4554

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2014-10-31 12:06 Lekensteyn 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] [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

2014-10-31 Thread Brad King 
On 10/30/2014 07:19 PM, Eric Wing wrote:
> Just curious, are the new WinRT changes the same exact changes from CMakeMS?

Yes.  After prototyping the changes in CMakeMS they worked with us
to contribute the functionality upstream.

-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 ...)'

2014-10-31 Thread Brad King 
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 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 ...)'

2014-10-31 Thread Ruslan Baratov via cmake-developers 

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 
  [DIRECTORY] # if present locked file will be /cmake.lock
(instead of )
  [RELEASE] # do explicit unlock
  [GUARD ] # if not present - set to `GUARD
PROCESS` (not used if RELEASE)
  [RESULT_VARIABLE ] # 0 on success, error message
otherwise; if not present - any error is FATAL_ERROR
  [TIMEOUT ]
  # 0 - return immediately if operation failed (try_lock),
otherwise timeout (timed_lock);
  # if not present - lock until success (or error);
  # not used if RELEASE;
)

That looks good.  The TIMEOUT unit can be 'seconds' but it should
accept a floating point value to get shorter times if possible.


Boost implementation of file locking mechanism use
LockFileEx/UnlockFileEx for windows and fcntl for unix-like platforms.
These functions lock file only for current process. When process crashes
lock removed by OS automatically.

Great!


I've tried (Un)LockFileEx/fcntl on windows (including mingw and cygwin),
linux and mac - works fine for me with one exception: cygwin's lock is
not visible by win32's lock. I.e. you can synchronize multiple cygwin
processes and multiple windows "normal" processes, but you can't mix them.

Thanks for testing.  The windows/cygwin mixing limitation is acceptable
IMO.

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] Expected difference in execute_process between MSYS / UNIX

2014-10-31 Thread Richard Shaw 
On Thu, Oct 30, 2014 at 2:25 PM, Brad King  wrote:

> On 10/30/2014 01:55 PM, Richard Shaw wrote:
> > I'm working on a big update to the FindFLTK module and I'm
> > testing it on all platforms I have access to.
> >
> > One problem that took me quite a while to figure out was that
> > on *nix systems, execute_process works with shell scripts but
> > on my MSYS2 install it does not, I have to prefix the command
> > with "sh" to make sure it executes in a shell.
> >
> > Is this known/expected?
>
> Yes.  It is not execute_process, but the underlying operating
> system process launching rules.  A shell script starts in a
> "shebang" (#!) line that the OS knows how to interpret to
> decide what program to run to launch the script.  Windows does
> not know how to do this so we have to specify a shell explicitly.
> MSYS is Windows, not POSIX/Cygwin.
>

I figured as much but wanted to verify.


> Should I prefix shell scripts with "sh" in all cases and not
> > count on it to work? Or should I test for MSYS and only prefix
> > the command with "sh" there?
>
> Using 'sh' should be safe.


Good to know. Thanks!

Richard
-- 

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