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.

[Ian Ni-Lewis (Google), 2015-10-30 14:57:02]

Description was changed from

==========
Changed 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.

Based on how the generator constructs paths, it seems apparent that
the intent was to use CMAKE_SOURCE_DIR as a base for paths relative
to the CMakeLists.txt being generated, 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.

BUG=
==========

to

==========
Changed 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.

Based on how the generator constructs paths, it seems apparent that
the intent was to use CMAKE_SOURCE_DIR as a base for paths relative
to the CMakeLists.txt being generated, 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.

BUG=
==========

[Ian Ni-Lewis (Google), 2015-10-30 14:57:02]

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

[bungeman-chromium, 2015-11-04 14:51:30]

bungeman@chromium.org changed reviewers:
+ bungeman@chromium.org

[bungeman-chromium, 2015-11-04 14:51:30]

Note that one needs to actually 'Publish+Mail Comments' for an email to be sent
out for the review. I found this because I created
https://codereview.chromium.org/1409753003/ and then went actively looking for
this one.

[bungeman-chromium, 2015-11-04 14:55:49]

https://codereview.chromium.org/1408993007/diff/20001/pylib/gyp/generator/cma...
File pylib/gyp/generator/cmake.py (right):

https://codereview.chromium.org/1408993007/diff/20001/pylib/gyp/generator/cma...
pylib/gyp/generator/cmake.py:1129: SetVariable(output, 'builddir',
'${CMAKE_CURRENT_LIST_DIR}')
Now this I object to. This change means generated output goes to the wrong
place. If there are gyp files out there making assumptions about where the build
directory is, that's a problem and those gyp files should be fixed. This seems
dangerous, as it is specifically causing files to be generated into non-build
directories.

[bungeman-chromium, 2015-11-04 15:00:12]

https://codereview.chromium.org/1408993007/diff/20001/pylib/gyp/generator/cma...
File pylib/gyp/generator/cmake.py (right):

https://codereview.chromium.org/1408993007/diff/20001/pylib/gyp/generator/cma...
pylib/gyp/generator/cmake.py:1129: SetVariable(output, 'builddir',
'${CMAKE_CURRENT_LIST_DIR}')
On 2015/11/04 14:55:49, bungeman2 wrote:
> Now this I object to. This change means generated output goes to the wrong
> place. If there are gyp files out there making assumptions about where the
build
> directory is, that's a problem and those gyp files should be fixed. This seems
> dangerous, as it is specifically causing files to be generated into non-build
> directories.

Did you want something like CMAKE_CURRENT_BINARY_DIR?

[Ian Ni-Lewis (Google), 2015-11-05 13:56:11]

Fixed builddir.

https://codereview.chromium.org/1408993007/diff/20001/pylib/gyp/generator/cma...
File pylib/gyp/generator/cmake.py (right):

https://codereview.chromium.org/1408993007/diff/20001/pylib/gyp/generator/cma...
pylib/gyp/generator/cmake.py:1129: SetVariable(output, 'builddir',
'${CMAKE_CURRENT_LIST_DIR}')
On 2015/11/04 15:00:12, bungeman2 wrote:
> On 2015/11/04 14:55:49, bungeman2 wrote:
> > Now this I object to. This change means generated output goes to the wrong
> > place. If there are gyp files out there making assumptions about where the
> build
> > directory is, that's a problem and those gyp files should be fixed. This
seems
> > dangerous, as it is specifically causing files to be generated into
non-build
> > directories.
> 
> Did you want something like CMAKE_CURRENT_BINARY_DIR?

That's exactly what I wanted, thanks.

[Mark Mentovai, 2015-11-05 14:28:46]

I don’t know cmake, but LGTM. If bungeman knows cmake, I defer to his review.

[bungeman-chromium, 2015-11-05 14:40:37]

Description was changed from

==========
Changed 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.

Based on how the generator constructs paths, it seems apparent that
the intent was to use CMAKE_SOURCE_DIR as a base for paths relative
to the CMakeLists.txt being generated, 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.

BUG=
==========

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-11-05 14:41:27]

lgtm

[bungeman-chromium, 2015-11-05 19:37:42]

Committed patchset #1 (id:1) manually as
0f5bae131e582e4cecc417d13ea0b8de440135c5 (presubmit successful).