Change CMAKE_SOURCE_DIR to CMAKE_CURRENT_LIST_DIR.

Change CMAKE_SOURCE_DIR to CMAKE_CURRENT_LIST_DIR.

In projects with just one CMakeLists.txt, these two variables
are equivalent. In multiproject builds, however, CMAKE_SOURCE_DIR
always points to the top level CMakeLists.txt while
CMAKE_CURRENT_LIST_DIR points to the CMakeLists.txt that is currently
being evaluated. CMAKE_CURRENT_LIST_DIR was added in cmake 2.8.3.

The generator constructs paths relative to the generated CMakeLists.txt
rather than to the build root. Therefore, CMAKE_CURRENT_LIST_DIR is the
more appropriate variable.

This change makes it possible to integrate a gyp-generated cmake
into a multi-project build without needing to switch the entire
build over to gyp. It also enables projects where the top level
cmake is handwritten (and possibly responsible for running gyp
to generate other cmake files). This makes usage in IDEs a bit
more convenient; at the very least, it stops CLion from complaining
that the source files don't live underneath the directory where
CMakeLists.txt lives. This also works with KDevelop, which has had
support for CMAKE_CURRENT_LIST_DIR since 4.1.

[bungeman-chromium, 2015-10-30 19:29:01]

Description was changed from

==========
Change CMAKE_SOURCE_DIR to CMAKE_CURRENT_LIST_DIR

In projects with just one CMakeLists.txt, these two variables
are equivalent. In multiproject builds, however, CMAKE_SOURCE_DIR
always points to the top level CMakeLists.txt while
CMAKE_CURRENT_LIST_DIR points to the CMakeLists.txt that is currently
being evaluated. CMAKE_CURRENT_LIST_DIR was added in cmake 2.8.3.

The generator constructs paths relative to the generated CMakeLists.txt
rather than to the build root. Therefore, CMAKE_CURRENT_LIST_DIR is the
more appropriate variable.

This change makes it possible to integrate a gyp-generated cmake
into a multi-project build without needing to switch the entire
build over to gyp. It also enables projects where the top level
cmake is handwritten (and possibly responsible for running gyp
to generate other cmake files). This makes usage in IDEs a bit
more convenient; at the very least, it stops CLion from complaining
that the source files don't live underneath the directory where
CMakeLists.txt lives. This also works with KDevelop, which has had
support for CMAKE_CURRENT_LIST_DIR since 4.1.
==========

to

==========
Change CMAKE_SOURCE_DIR to CMAKE_CURRENT_LIST_DIR.

In projects with just one CMakeLists.txt, these two variables
are equivalent. In multiproject builds, however, CMAKE_SOURCE_DIR
always points to the top level CMakeLists.txt while
CMAKE_CURRENT_LIST_DIR points to the CMakeLists.txt that is currently
being evaluated. CMAKE_CURRENT_LIST_DIR was added in cmake 2.8.3.

The generator constructs paths relative to the generated CMakeLists.txt
rather than to the build root. Therefore, CMAKE_CURRENT_LIST_DIR is the
more appropriate variable.

This change makes it possible to integrate a gyp-generated cmake
into a multi-project build without needing to switch the entire
build over to gyp. It also enables projects where the top level
cmake is handwritten (and possibly responsible for running gyp
to generate other cmake files). This makes usage in IDEs a bit
more convenient; at the very least, it stops CLion from complaining
that the source files don't live underneath the directory where
CMakeLists.txt lives. This also works with KDevelop, which has had
support for CMAKE_CURRENT_LIST_DIR since 4.1.
==========

[bungeman-chromium, 2015-10-30 19:29:39]

bungeman@chromium.org changed reviewers:
+ ilewis@google.com

[bungeman-chromium, 2015-10-30 19:55:46]

Apparently the win and win_try bots have been offline for a while, and the
linux_try no longer runs the cmake tests. I ran the cmake tests locally, and
this doesn't change anything there.

[bungeman-chromium, 2015-11-05 19:40:47]

Closed after committing https://codereview.chromium.org/1408993007/ .