Re: [PATCH 0/8] CMake build system for git

[Junio C Hamano <gitster@pobox.com>]

Sibi Siddharthan <sibisiddharthan.github@gmail.com> writes:

> Yes, this is trivial, but doing so is bad practice in general and
> difficult to maintain.

Can you substantiate "bad" and "difficult" in the above sentence?

They are so subjective words and sounds more of your "opinion" than
generally accepted "fact".

> Won't it be better just to copy the CMakeLists.txt to the root
> directory for configuring.

I do not know it is better or not compared to using directly from a
subdirectory.  But it is easy to see that it is a bad practice to
keep the source of truth in contrib/cmake/CMakeLists.txt and use it
by copying it to the top of the working tree.  

The reason would be obvious once you imagine what happens when those
who are helping to improve CMake support find that they need to make
changes.  It is too easy to edit the one they copied to the top of
the working tree until they manage to get it working, and then
forget to copy it back to contrib/cmake/ before committing the
change [*1*].

Compared to that, the way Konstantin showed, which is just to be at
the top of the working tree and run the cmake command with a single
argument, which is the path to the CMakeList.txt file, looked quite
simple and straight-forward to an untrained eye that hsan't seen a
real use of CMake.  But there must be reasons, coming from lessons
learned by using CMake with a CMakeList.txt file in a subdirectory
and suffering the consequences of doing so, that makes you say it is
a bad practice and difficult to maintain.  It needs to be spelled
out to help those who do not know CMake understand.

Thanks.


[Footnote]

*1* Creating a symlink CMakeLists.txt at the top of the working tree
that points into contrib/cmake/CMakeLists.txt (and it needs to be
done only once) would avoid such a problem, but if your filesystem
does not let you use a symlink, copying a skeletal CMakeLists.txt
that nobody is expected to modify to the top of the working tree
might be an acceptable workaround.  The sole purpose of that
skeletal CMakeLists.txt at the top of the working tree would be to
include the "real" thing in contrib/cmake/ directory (I am assuming
that CMake is capable of including a CMakeLists.txt file that exists
elsewhere in another CMakeLists.txt file).

With either of these arrangements, it is much less likely for the
user to accidentally edit a "wrong" copy and forgets to update the
real thing---the real thing stored in contrib/cmake will be the only
one that would be edited.