Re: [cmake-developers] cmake daemon mode protocol
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, not a builddir. At th
Re: [cmake-developers] cmake daemon mode protocol
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
Re: [cmake-developers] cmake daemon mode protocol
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
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
[cmake-developers] [PATCH] Added FILTER subcommand to list command
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-developers] [CMake 0015922]: Unable to configure Fortan through minGW with Visual Studio 14
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 confi