At this point, it reads/writes on stdin/stdout. This can be changed to
use local sockets/named pipes when appropriate.  At that point, the
magic string wrapping is also not needed.

This is needed on Windows at least, but this is something for a Windows
expert to look into.

I must be missing something in libuv, because this should be easier.

A client request of

 [== CMake MetaMagic ==[
 {"type":"buildsystem"}
 ]== CMake MetaMagic ==]

results in a response describing all targets.

This should provide the compile definitions, include directories etc
as JSON properties, but should also provide the full command line
content (including ordering of include directories, content of
CMAKE_CXX_FLAGS etc) which gets passed to the compiler, if that is
possible to do.

Use the stdin and stdout features of the subprocess module to interact
with the cmake process.

    $ ./daemon-client.py /path/to/kitemmodels/build
    Serving

      Source Dir: /path/to/kitemmodels
      Binary Dir: /path/to/kitemmodels/build
      Project: KItemModels

    Targets
        KF5ItemModels                    krecursivefilterproxymodeltest   proxymodeltestapp
        kdescendantsproxymodel_smoketest kselectionproxymodel_smoketest   proxymodeltestsuite
        klinkitemselectionmodeltest      kselectionproxymodeltest         testmodelqueuedconnections

    Select a target:

User inputs: "KF5Item"

    Corrected "KF5Item" to "KF5ItemModels"

    Sources
        /path/to/kitemmodels/src/kbreadcrumbselectionmodel.cpp  /path/to/kitemmodels/src/kmodelindexproxymapper.cpp
        /path/to/kitemmodels/src/kcheckableproxymodel.cpp       /path/to/kitemmodels/src/krecursivefilterproxymodel.cpp
        /path/to/kitemmodels/src/kdescendantsproxymodel.cpp     /path/to/kitemmodels/src/kselectionproxymodel.cpp
        /path/to/kitemmodels/src/klinkitemselectionmodel.cpp

    Generated Sources
        /path/to/kitemmodels/build/src/KF5ItemModels_automoc.cpp

    Include Directories
        /path/to/kitemmodels/build/src       /path/to/qtbase/include           /path/to/qtbase/mkspecs/linux-g++
        /path/to/kitemmodels/src             /path/to/qtbase/include/QtCore

    Compile Definitions
        _GNU_SOURCE                  QT_NO_CAST_FROM_ASCII        QT_NO_SIGNALS_SLOTS_KEYWORDS QT_CORE_LIB
        _LARGEFILE64_SOURCE          QT_NO_URL_CAST_FROM_STRING   QT_USE_FAST_OPERATOR_PLUS    QT_NO_DEBUG
        QT_NO_CAST_TO_ASCII          QT_NO_CAST_FROM_BYTEARRAY    QT_USE_QSTRINGBUILDER

    Compile Options
        <None>

Make it easier to record which conditions were tested, and which were
true.

TODO: Is this needed at all?

TODO: I'm not sure this behaves correctly when a macro is defined in one
file and called in another.  See eg the tool running on the llvm
buildsystem.

TODO: Properly handle aborting commands such as break(), continue(),
return() etc so that following lines are marked not executed.

Treat it as a normal mode.

Make different behavior possible for the cmake server.

These can be made at an arbitrary point and do not create a scope.

TODO: The cmState is getting unwieldy. Consider redesigning the data
tracking based on shared_ptr per Sean Parent.

These are:

 * Just after a project()
 * Just after a find_package()
 * Just after a include()
 * Just after a add_subdirectory()
 * Just inside a macro or function definition
 * Just outside a macro or function definition
 * Just after a macro or function invocation

These can be used as starting points to provide recorded data through
the server.

Other places these should be created:

* After any execute_process
* After any file(WRITE)
* After configure_file, or does that only have an effect on change?
* After try_compile, or does that only have an effect on cache change?

This breaks the file_info protocol, but may be needed for code
completion.

This is so that the server can access all snapshots.

Is this the right approach?

A particular context in a listfile may be executed multiple times, for
example if inside a function which is executed multiple times. Provide
all available snapshots for each context.

Commands know the type of arguments expected. That can be used for
code completion and contextual help.

The level of completion of this is quite mixed. The API in cmCommand may
not be the most ideal for what is needed.

At least at some point I hit this assert.

Needed for code completion.

This is not acceptable for master. Instead the parser should be made
failsafe in a more-deliberate way.

Using the dtl: git@github.com:cubicdaiya/dtl.git

I think the dtl::Diff object takes an unnecessary copy of each
std::string line. Perhaps that can be avoided.

TODO: Edit cmListFileLexer.in.l and regenerate instead?

Coverage needs to be higher here.

The server needs to be able to execute commands as they exist in
an editor buffer, not on the filesystem.  This allows executing them
after parsing.

The protocol currently requires the client to sent the entire editor
content as a JSON value.  The protocol should be extended to accept a
filepath where the editor content is stored.  Editors like vim keep such
a file.

Also to be considered is extending the protocol to allow editors to
specify only changed lines.

This works by first parsing the file on disk, and using the resulting
parsed data to find the end of a command before a diff'd chunk.  That
way the parser can read an entire command in the changed chunk instead
of starting in the middle of an argument for example.

TODO: Instead of duplicating the parser, refactor the existing parser
into a visitor pattern or so to facilitate re-use in this context.

Ugly levels of nesting in the code here.  Needs to be rewritten.

This is only half done (needs to execute commands to find the correct
line where the variable gets set) and uses a big hack of making use of
the code completion infrastructure to find a variable. That should be
refactored.

currently daemon returns nothing, which effectively hangs the client
if it permanently waits for daemon response. this adds error return
in the daemon when error occurs, thus unblocking the client. another
approach is to always have the client to use timed wait. but I think
a good server should try to be responsive in all cases.

allow client to send {'type':'quit'} to quit the daemon.