allowing it to discover PYTHON_INCLUDE_DIR and PYTHON_LIBRARY
Also changed wrap_python.hpp to only check for defined(__CYGWIN__)
on 32-bit systems. Previously this check was OR'd with the check
for defined(__WIN32__) causing the system to erroneously update the
SIZEOF_LONG value and subsequently resulting in "make ycm_core"
failing with "LONG_BIT definition appears wrong for platform" on
CYGWIN-64 systems.
When I initially released this project, I released it under my own copyright. I
have since then worked on it in my 20% time at Google (and want to continue
doing this) and my life becomes much simpler if the copyright is Google's.
From the perspective of how this project is run and managed, **NOTHING**
changes. YCM is not a Google product, merely a project run by someone who just
happens to work for Google.
Please note that the license of the project is **NOT** changing.
People sending in future pull requests will have to sign the Google
[CLA](https://developers.google.com/open-source/cla/individual) (you can sign
online at the bottom of that page) before those pull requests could be merged
in. People who sent in pull requests that were merged in the past will get an
email from me asking them to sign the CLA as well.
Checking the path is set is not enough, we should also check the path
exists. This allows people to have a general-purpose
.ycm_extra_conf.conf that automatically loads a database file if exists,
and falls back to the manual flags if not.
ycmd would sometimes crash on startup with a coredump and a message from glibc
on how free() was called for an invalid pointer. A gdb session pointed out that
the problem was with static initialization order.
This means we can now load just ycm_client_support (which is a much smaller
library) into Vim and ycm_core into ycmd. Since ycm_client_support never depends
on libclang.so, we never have to load that into Vim which makes things much,
much easier.
Now, every FileReadyToParse event returns diagnostics, if any. This is instead
of the previous system where the diagnostics were being fetched in a different
request (this caused race conditions).
There appear to be timing issues for the diag requests. Somehow, we're sending
out-of-date diagnostics and then not updating the UI when things change.
That needs to be fixed.
The server is multi-threaded and will spawn a new thread for each new request.
Thus, the completers need not manage their own threads or even provide async
APIs; we _want_ them to block because now were implementing the request-response
networking API.
The client gets the async API through the network (i.e., it can do something
else while the request is pending).
