date:20160116

Re: [cmake-developers] cmake daemon mode protocol

2016-01-16 Thread Tobias Hunger

Hi Stephen,

I think what I suggested so far is covered by the first way of
interaction covered in
http://thread.gmane.org/gmane.comp.lib.qt.creator/11794/focus=15411 .

I am just proposing something that is convenient for me to use.

On Sat, Jan 16, 2016 at 12:26 PM, Stephen Kelly  wrote:
>>> For this case, I suggest that if the user tries to 'open the source
>>> directory', you would use QTemporaryDir to build in a temporary location
>> and
>>> run the daemon there. I believe clion does something equivalent to that.
>>> Is that viable? I suppose you are suggesting that cmake do that instead
>>> of leaving it for clients to do?
>>
>> It is doable. I just do not see why this should be necessary.
>
> I'm aiming to first design as much as possible of a 'minimal viable
> protocol' as a first step. Given the above I think your ideas of running the
> daemon with no build dir are not 'minimal' and I'm convinced they're not
> viable.

I am thinking about the simplest possible use-case I can think of
right now: User gets sources from a project somewhere and wants to
build those.

What is entirely unclear to me with your current implementation is how
do I get from "sources are checked out in $DIR" to "I have a $BUILD
that I can use to start the daemon"?

Then I also do not see how I can support a user switching between two
build directories. Do I need to close down one daemon and start
another?

> Someone would have to prototype the ideas, but I don't think that's a good
> use of time or energy right now (mostly because I think they're not viable).
>
> I recommend focussing on the tasks in my OP:
>
>  http://thread.gmane.org/gmane.comp.lib.qt.creator/11794

That list is so full of cmake internals that it is basically
meaningless to me. Sorry.

>>> Richer information about some semantics like 'task' and 'busy state'
>>> could also be provided in a similar way I expect, assuming those could be
>> defined.
>>
>> This is some basic functionality that we should get right soon, as this
>> can influence how long-running tasks need to be designed.
>
> Yes. Perhaps you can expand on what 'tasks' and 'busy state' you have in
> mind. Particularly if you can relate them to what is already in my github
> branch.

"task" is just some Id to identify what the daemon is currently doing.
"state" is just some indication of whether the daemon thinks it is
busy with something or not. In "idle" state it should accept more
requests, in "busy" state it will just queue them or maybe even ignore
them.

>> So "cmake --build" is out of scope for the daemon?
>
> I listed three ways cmake and an IDE could interface here:
>
>  http://thread.gmane.org/gmane.comp.lib.qt.creator/11794/focus=15411
>
> 'triggering the build' would be a fourth. I don't think it needs to be part
> of the initial discussion of the design.
>
> Let's try to keep scope small so that we can get on common ground.

So let's forget about all the interactive stuff for now. That is IMHO
step 2, after the basic protocol is validated by implementing bare
bones project information:-)

>> That is why I brought up progress information so early: They make things
>> complicated by there suddenly being several responses to a request and you
>> need a way to identify those. At that point simpler solutions tend to blow
>> up:-)
>
> Yes.
>
> BTW: I don't expect to get any part of the design of the protocol 'right' on
> the first iteration. I think we need to start everything that will need to
> be in the protocol, then iterate. Start high level ignoring details, and
> fill in the details as we iterate and can encode needs in unit tests.

I agree and do not expect anything different.

Basic protocol functionality from my point of view needs to include:
* Being able to detect the daemon or IDE becoming unresponsive
* Being able to find which responses are the result of which requests
* Being able to reliably find what kind of object I got as request or response

>From the point of view of an IDE: Being able to have progress
information is not a high level detail to be filled in later.

Best Regards,
Tobias
-- 

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 daemon mode protocol

2016-01-16 Thread Tobias Hunger

Hi Stephen,

Am 15.01.2016 00:38 schrieb "Stephen Kelly" :
> > * Start daemon-mode without any additional parameters
> >
> > * Daemon responds with "
> >   {
> > "type": "handShake",
> > "version": "3.5.x",
> > "supportedProtocols": "3.5"
> >   }
>
> As you discovered, the cmake binary might not even support the daemon mode
> at all.

That is really straight forward to detect: It will send malformed JSON on
stdout if daemon-mode is unsupported:-) The error message you get is not
JSON and definitely on of type handShake.

> I think what you are really asking for is 'the capabilities of the cmake
> binary'. In that sense, you might also want to know what generators are
> available, whether daemon mode is available (and with which protocol
> versions) etc.
>
> The issue at
>
>  http://public.kitware.com/Bug/view.php?id=15462
>
> proposes to dump that information to stdout with a different -E command.

I do not really see the need for that.

Daemon-mode is easy to detect by the reply to the attempt to start it.

Everything else I expect to extract from within daemon mode.

> >
> > * Client Handshake:
> >   {
> > "type": "handshake",
> > "requestProtocolVersion": "3.5"
> >   }
> >
> > * Daemon:
> >   {
> > "type:"handshake",
> > "protocolVersion": "3.5"
> >   }
>
> Something like this is possible too. It's not far off what is already done
> in the branch.

I know, that is what this is based on after all. All I want is to be able
to start daemon-mode without having a builddir that is already associated
with a sourcedir.

> > At this point the normal operation should be possible.
> >
> > * Client:
> >   {
> >  "type": "setProjectInformation",
> >  "sourceDirectory": "/some/path",
> >  "cookie": "1"
> >   }
> >
> >   Being able to set the source directory is important so that a fresh
> > checkout can be configured. There is no build directory available at
> > that time...
>
> I understand the desire to inspect a cmake project without asking the user
> to specify a build dir,

You can safely read the CMakelists at this point, give syntax errors, maybe
even extract basic information like project name at this point.

> but cmake has to write build files somewhere in
> order to test the compiler etc.

If this works with a temporary build directory, then these files probably
do not need to litter the build directory in the first place:-)

> For this case, I suggest that if the user tries to 'open the source
> directory', you would use QTemporaryDir to build in a temporary location
and
> run the daemon there. I believe clion does something equivalent to that.

Hey, the idea is to improve on the current situation, not to perpetuate the
workarounds.

And how do I associate an empty directory as a builddir to a sourcedir?

How can I switch between builds when the daemon-mode is set up to work with
one builddir? Do I have to close it down and start a new daemon for the
next build?

That would be suboptimal, as all the built-in dependent state of the
project would need to get regenerated by the new daemon. Associating a
daemon with a sourcedir and being able to switch builddir would be nicer.

> Is that viable? I suppose you are suggesting that cmake do that instead of
> leaving it for clients to do?

It is doable. I just do not see why this should be necessary.

The daemon is not need to persist its state to disk all the time like
command-based cmake currently needs to.

> > * Daemon should do progress handling while reading the CMakeLists.txt
> > or whatever it does:
> >   { "type": "progress", "state": "busy", "task": "someId",
> > "taskDescription": "Reading CMakeLists.txt files", "cookie": "1" }
> >
> > * Daemon sends occasional:
> >   { "type": "progress", "task": "someId", progressTotal: 25,
> > progressCurrent: 12, "cookie": "1" }
>
> Yes. CMake can provide approximate values of how complete the configure
step
> is. See cmGlobalGenerator::AddMakefile. That could be exposed to the
daemon
> 'somehow', such as by defining some virtual callback interface.
>
> Richer information about some semantics like 'task' and 'busy state' could
> also be provided in a similar way I expect, assuming those could be
defined.

This is some basic functionality that we should get right soon, as this can
influence how long-running tasks need to be designed.

> > * Finally Daemon responds sends data as that is available now.
> >   {
> > "type": "projectInformation",
> > "sourceDirectory": "/some/path",
> > "buildDirectory": "",
> > "projectName": "SomeProject",
> > "cookie": "1"
> >   }
>
> At this point in your proposal, cmake has run the configure step in a
> temporary directory, right?

I am currently arguing with complete ignorance of how cmake works
internally:-) This is just what I think makes the most sense from an IDE
perspective.

> So it would be
>
>   "buildDirectory": "/tmp/foo/bar"
>
> right?

No.

The daemon should be associated with a sourcedir,

Re: [cmake-developers] cmake daemon mode protocol

2016-01-16 Thread Stephen Kelly

Stephen Kelly wrote:
> I recommend focussing on the tasks in my OP:
> 
>  http://thread.gmane.org/gmane.comp.lib.qt.creator/11794

To be more clear:

The goal I have is to enable debugging, introspection of the buildsystem and 
the state during execution, code completion etc.

Your goal seems to be completely orthogonal to that and requires an entirely 
different set of steps to achieve (perhaps the first being 'demonstrate 
viability'). I don't think I can help with your goal.

Thanks,

Steve.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] cmake daemon mode protocol

2016-01-16 Thread Stephen Kelly

Tobias Hunger wrote:

>> For this case, I suggest that if the user tries to 'open the source
>> directory', you would use QTemporaryDir to build in a temporary location
> and
>> run the daemon there. I believe clion does something equivalent to that.
>> Is that viable? I suppose you are suggesting that cmake do that instead
>> of leaving it for clients to do?
> 
> It is doable. I just do not see why this should be necessary.

I'm aiming to first design as much as possible of a 'minimal viable 
protocol' as a first step. Given the above I think your ideas of running the 
daemon with no build dir are not 'minimal' and I'm convinced they're not 
viable. 

Someone would have to prototype the ideas, but I don't think that's a good 
use of time or energy right now (mostly because I think they're not viable).

I recommend focussing on the tasks in my OP:

 http://thread.gmane.org/gmane.comp.lib.qt.creator/11794

>> Richer information about some semantics like 'task' and 'busy state'
>> could also be provided in a similar way I expect, assuming those could be
> defined.
> 
> This is some basic functionality that we should get right soon, as this
> can influence how long-running tasks need to be designed.

Yes. Perhaps you can expand on what 'tasks' and 'busy state' you have in 
mind. Particularly if you can relate them to what is already in my github 
branch.

> So "cmake --build" is out of scope for the daemon?

I listed three ways cmake and an IDE could interface here:

 http://thread.gmane.org/gmane.comp.lib.qt.creator/11794/focus=15411

'triggering the build' would be a fourth. I don't think it needs to be part 
of the initial discussion of the design. 

Let's try to keep scope small so that we can get on common ground.

> That is why I brought up progress information so early: They make things
> complicated by there suddenly being several responses to a request and you
> need a way to identify those. At that point simpler solutions tend to blow
> up:-)

Yes.

BTW: I don't expect to get any part of the design of the protocol 'right' on 
the first iteration. I think we need to start everything that will need to 
be in the protocol, then iterate. Start high level ignoring details, and 
fill in the details as we iterate and can encode needs in unit tests.

Thanks,

Steve.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0015922]: Unable to configure Fortan through minGW with Visual Studio 14

2016-01-16 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15922 
== 
Reported By:Alex Ghosh
Assigned To:
== 
Project:CMake
Issue ID:   15922
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-16 20:49 EST
Last Modified:  2016-01-16 20:49 EST
== 
Summary:Unable to configure Fortan through minGW with Visual
Studio 14
Description: 
I am trying to compile a fortran/c++ code to build SNOPT for windows. I have
extracted all the C++ related issues and are still having problems with the core
Fortran compilation using Visual Studio and minGW. The sub-project is valid and
will configure and make a minGW makefile just fine. When I try to then use the
cmake_add_fortran_subdirectory() features, at the configuration level I receive
the error output shown in the additional information. All attempts for for an
win64 target.



Steps to Reproduce: 
1) Install Visual Studio 2015 (tested with Enterprise, but also occured with VS
2013 Community)
2) Install mingw-64 from sourceforge
3) See the attached CMakeList for the root directory. Substitute any fortran
project for the sub-directory, which has a valid, functional CMakeLists.txt
project.
4) Attempt to configure.

Additional Information: 
The Fortran compiler identification is unknown
The CXX compiler identification is MSVC 19.0.23506.0
Check for working Fortran compiler using: Visual Studio 14 2015 Win64
Check for working Fortran compiler using: Visual Studio 14 2015 Win64  -- broken
CMake Error at C:/Program Files
(x86)/CMake/share/cmake-3.4/Modules/CMakeTestFortranCompiler.cmake:54 (message):
  The Fortran compiler "C:/mingw-64/mingw64/bin/gfortran.exe" is not able to
  compile a simple test program.

  It fails with the following output:

   Change Dir: C:/snopt74/build/CMakeFiles/CMakeTmp

  

  Run Build Command:"C:/Program Files (x86)/Microsoft Visual Studio
  14.0/Common7/IDE/devenv.com" "CMAKE_TRY_COMPILE.sln" "/build" "Debug"
  "/project" "cmTC_f832e"

  


  Microsoft Visual Studio 2015 Version 14.0.24720.0.


  Copyright (C) Microsoft Corp.  All rights reserved.


  


  Some errors occurred during migration.  For more information, see the
  migration report:


  C:\snopt74\build\CMakeFiles\CMakeTmp\UpgradeLog.htm


  


  The operation could not be completed 


  


  Use:


  devenv [solutionfile | projectfile | anyfile.ext] [switches]


  


  The first argument for devenv is usually a solution file or project file.


  You can also use any other file as the first argument if you want to have
  the


  file open automatically in an editor.  When you enter a project file, the
  IDE


  looks for an .sln file with the same base name as the project file in the


  parent directory for the project file.  If no such .sln file exists, then
  the


  IDE looks for a single .sln file that references the project.  If no such
  single


  .sln file exists, then the IDE creates an unsaved solution with a default
  .sln


  file name that has the same base name as the project file.


  


  Command line builds:


  devenv solutionfile.sln /build [ solutionconfig ] [ /project
  projectnameorfile [ /projectconfig name ] ]


  Available command line switches:


  


  /BuildBuilds the solution or project with the specified 
solution


configuration.  For example "Debug".  If multiple platforms


are possible, the configuration name must be enclosed in quotes


and contain platform name.  For example: "Debug|Win32".


  /CleanDeletes build outputs.


  /Command  Starts the IDE and executes the command.


  /Deploy   Builds and then deploys the specified build 
configuration.


  /Edit Opens the specified files in a running instance of this


application.  If there are no running instances, it will


start a new instance with a simplified window layout.


  /LCID Sets the default language in the IDE for the UI.


  /Log  Logs IDE activity to the specified file for troubleshooting.


  /NoVSIP   Disables the VSIP developer's license key for VSIP 
testing.


  /Out  Appends the build log to a specified file.


  /Project  Specifies the project to build, clean, or deploy.


Must be used with /Build, /Rebuild, /Clean, or /Deploy.


  /ProjectConfigOverrides the project

[cmake-developers] [PATCH] Added FILTER subcommand to list command

2016-01-16 Thread Ashley Whetter

In response to issue 0003986, I've implemented a FILTER subcommand to the "list"
command that filters a list using a regular expression.
This doesn't implement an optional "OUTPUT_VARIABLE" parameter.

There was a discussion on the issue as to whether or not the user using a macro
would be a better option. Therefore I've submitted a sample macro for the
reporter on the issue as well if this patch isn't accepted.

---
 Help/command/list.rst  | 12 +++--
 Source/cmListCommand.cxx   | 54 ++
 Source/cmListCommand.h |  1 +
 Tests/RunCMake/list/EmptyFilter-result.txt |  1 +
 Tests/RunCMake/list/EmptyFilter-stderr.txt |  0
 Tests/RunCMake/list/EmptyFilter.cmake  |  2 +
 Tests/RunCMake/list/FILTER-InvalidRegex-result.txt |  1 +
 Tests/RunCMake/list/FILTER-InvalidRegex-stderr.txt |  4 ++
 Tests/RunCMake/list/FILTER-InvalidRegex.cmake  |  2 +
 Tests/RunCMake/list/FILTER-NotList-result.txt  |  1 +
 Tests/RunCMake/list/FILTER-NotList-stderr.txt  |  4 ++
 Tests/RunCMake/list/FILTER-NotList.cmake   |  2 +
 .../list/FILTER-TooManyArguments-result.txt|  1 +
 .../list/FILTER-TooManyArguments-stderr.txt|  4 ++
 Tests/RunCMake/list/FILTER-TooManyArguments.cmake  |  1 +
 Tests/RunCMake/list/FILTER-Valid0-result.txt   |  1 +
 Tests/RunCMake/list/FILTER-Valid0-stderr.txt   |  2 +
 Tests/RunCMake/list/FILTER-Valid0.cmake|  4 ++
 Tests/RunCMake/list/RunCMakeTest.cmake |  6 +++
 19 files changed, 100 insertions(+), 3 deletions(-)
 create mode 100644 Tests/RunCMake/list/EmptyFilter-result.txt
 create mode 100644 Tests/RunCMake/list/EmptyFilter-stderr.txt
 create mode 100644 Tests/RunCMake/list/EmptyFilter.cmake
 create mode 100644 Tests/RunCMake/list/FILTER-InvalidRegex-result.txt
 create mode 100644 Tests/RunCMake/list/FILTER-InvalidRegex-stderr.txt
 create mode 100644 Tests/RunCMake/list/FILTER-InvalidRegex.cmake
 create mode 100644 Tests/RunCMake/list/FILTER-NotList-result.txt
 create mode 100644 Tests/RunCMake/list/FILTER-NotList-stderr.txt
 create mode 100644 Tests/RunCMake/list/FILTER-NotList.cmake
 create mode 100644 Tests/RunCMake/list/FILTER-TooManyArguments-result.txt
 create mode 100644 Tests/RunCMake/list/FILTER-TooManyArguments-stderr.txt
 create mode 100644 Tests/RunCMake/list/FILTER-TooManyArguments.cmake
 create mode 100644 Tests/RunCMake/list/FILTER-Valid0-result.txt
 create mode 100644 Tests/RunCMake/list/FILTER-Valid0-stderr.txt
 create mode 100644 Tests/RunCMake/list/FILTER-Valid0.cmake

diff --git a/Help/command/list.rst b/Help/command/list.rst
index a7a05c7..797cc14 100644
--- a/Help/command/list.rst
+++ b/Help/command/list.rst
@@ -9,6 +9,7 @@ List operations.
   list(GET   [ ...]
)
   list(APPEND  [ ...])
+  list(FILTER  )
   list(FIND   )
   list(INSERT[ ...])
   list(REMOVE_ITEM   [ ...])
@@ -23,6 +24,11 @@ List operations.
 
 ``APPEND`` will append elements to the list.
 
+``FILTER`` will remove the items from the list that match the given regular
+expression.
+For more information on regular expressions see also the :command:`string`
+command.
+
 ``FIND`` will return the index of the element specified in the list or -1
 if it wasn't found.
 
@@ -38,9 +44,9 @@ difference is that ``REMOVE_ITEM`` will remove the given 
items, while
 
 ``SORT`` sorts the list in-place alphabetically.
 
-The list subcommands ``APPEND``, ``INSERT``, ``REMOVE_AT``, ``REMOVE_ITEM``,
-``REMOVE_DUPLICATES``, ``REVERSE`` and ``SORT`` may create new values for
-the list within the current CMake variable scope.  Similar to the
+The list subcommands ``APPEND``, ``INSERT``, ``FILTER``, ``REMOVE_AT``,
+``REMOVE_ITEM``, ``REMOVE_DUPLICATES``, ``REVERSE`` and ``SORT`` may create new
+values for the list within the current CMake variable scope.  Similar to the
 :command:`set` command, the LIST command creates new variable values in the
 current scope, even if the list itself is actually defined in a parent
 scope.  To propagate the results of these operations upwards, use
diff --git a/Source/cmListCommand.cxx b/Source/cmListCommand.cxx
index 6041fb7..bafd647 100644
--- a/Source/cmListCommand.cxx
+++ b/Source/cmListCommand.cxx
@@ -14,6 +14,7 @@
 #include 
 #include "cmAlgorithms.h"
 
+#include 
 #include  // required for atoi
 #include 
 #include 
@@ -68,6 +69,10 @@ bool cmListCommand
 {
 return this->HandleReverseCommand(args);
 }
+  if(subCommand == "FILTER")
+{
+return this->HandleFilterCommand(args);
+}
 
   std::string e = "does not recognize sub-command "+subCommand;
   this->SetError(e);
@@ -517,3 +522,52 @@ bool cmListCommand::HandleRemoveAtCommand(
   return true;
 }
 
+//
+class MatchesRegex {
+public:
+  MatchesRegex(cmsys::RegularExpression& in_regex) : regex(in_regex) {}
+
+  bool operator()(const std::string& target) {
+

Re: [CMake] Changing the the current generator in CMake GUI

2016-01-16 Thread iosif neitzke


http://reactiongifs.me/krysten-ritter-eyeroll/
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.4.1-849-g27410a9

2016-01-16 Thread Kitware Robot

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  27410a9c62f883f3bada885b0ef6cdb343ea40b5 (commit)
  from  66942a764cd7692921080247e184b26d43140e54 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27410a9c62f883f3bada885b0ef6cdb343ea40b5
commit 27410a9c62f883f3bada885b0ef6cdb343ea40b5
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Sun Jan 17 00:01:07 2016 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Sun Jan 17 00:01:07 2016 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 39c0347..7e895f3 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 4)
-set(CMake_VERSION_PATCH 20160116)
+set(CMake_VERSION_PATCH 20160117)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] cmake daemon mode protocol

Re: [cmake-developers] cmake daemon mode protocol

Re: [cmake-developers] cmake daemon mode protocol

Re: [cmake-developers] cmake daemon mode protocol

[cmake-developers] [CMake 0015922]: Unable to configure Fortan through minGW with Visual Studio 14

[cmake-developers] [PATCH] Added FILTER subcommand to list command

Re: [CMake] Changing the the current generator in CMake GUI

[Cmake-commits] CMake branch, master, updated. v3.4.1-849-g27410a9

8 matches

Site Navigation

Mail list logo

Footer information