Re: [RFC PATCH 0/1] Implement CMake build

From: Isaac Hier <isaachier@gmail.com>
Date: Jan 24, 2018, 19:59 UTC
Message-ID: <CAG6xkCbe+pLwTCButZGdPucHoRCq-a8mWfifd6z2bzGZNseE9A@mail.gmail.com>
In-Reply-To: <675fa58d-bff3-d7e4-5fac-ecf1401932f4@jeffhostetler.com>

Jeff, no worries, fair enough. I know https://github.com/grpc/grpc uses a shared file to generate code for several build systems instead of maintaining them individually. I plan on doing the work anyway just because I have my own reasons to use CMake in Git (for packaging in https://github.com/ruslo/hunter is my main motive here). Whether or not it is maintained upstream is not a real concern for me at the moment.

Junio, in terms of maintainability, yes that is my main concern as well. I proposed this here knowing that might be the main issue. From my point of view, CMake is a much better choice than Makefile + uname overrides, but if no one cares for learning CMake, you are correct that it will not be maintained.

In terms of the benefits of CMake, let me highlight some examples I noticed while porting this:

* Makefiles rely on hard-coded paths. CMake does not (uses find,
configs, etc. to alleviate path-related issues). One clear example is
the way the Makefile has to exclude certain package manager paths on
Mac (i.e. fink and ports).
* Makefiles do not have a good way of finding dependencies or checking
versions. Compare these two choices.
   Makefile: curl_check := $(shell (echo 070908; $(CURL_CONFIG)
--vernum | sed -e '/^70[BC]/s/^/0/') 2>/dev/null | sort -r | sed -ne
2p)
   CMakeLists.txt:  if(CURL AND CURL_VERSION_STRING
VERSION_GREATER_EQUAL "7.22.0")
* Makefile cannot use compilation results to drive build.
config.mak.uname needs to be updated each and every time to delineate
acceptable builds.
* CMake can automatically produce a compilation database for clang
tools (iwyu, clang-tidy, etc.).
* CMake is procedural and generates a dataflow Makefile. Procedural
programming is a little more intuitive IMO, especially true for C
programmers :). Case in point, debugging a Makefile is a lot harder
than debugging CMake.
* CMake is compatible with non-Unix/Windows platforms.

My point isn't to convert you, just to explain why CMake has taken over in many many projects over the last decade. I agree that if there is no maintainer, do not accept this patch. I'm only offering it in case there is any interest. It seems like there isn't at the moment. I'll see how the Windows build currently works and if that makes sense, maybe I'll try using that build generator here too.

Thanks for the feedback,

Isaac

On Wed, Jan 24, 2018 at 2:36 PM, Jeff Hostetler <git@jeffhostetler.com> wrote:

Show 58 quoted lines

>
>
> On 1/22/2018 7:16 PM, Isaac Hier wrote:
>>
>> This patch adds a mostly complete (aside from building tests,
>> documentation,
>> installation, etc.) CMake build to the git project. I am not sure how much
>> interest there is in a CMake build, so please send me feedback one way or
>> another. Personally, I believe CMake will help with Windows builds and is
>> somewhat easier to read than a Makefile. I considered, adding this to the
>> contrib directory, but CMakeLists.txt almost always reside in the original
>> directories, and I'm not sure how wise it would be to do otherwise. If you
>> are
>> interested in a CMake build, I would be more than happy to finish up the
>> work
>> here. Decided to wait until I discussed the issue here to finish the final
>> parts
>> of the build.
>
>
> On Windows, we use "bash" and "make" from the Git-for-Windows SDK
> installation
> (which gives us a bash shell and most of the usual Unix command line tools)
> and
> the main "Makefile".  We do need a special section in the "config.mak.uname"
> file
> to set some platform compiler options and etc., but that is small enough.
>
> Johannes and I recently added a few new options to let Windows build Git
> from
> the command line with either GCC or MSVC and to synthesize MSVS solution
> (.sln)
> and project (.vcxproj) files to allow you to work with the full MSVS IDE and
> full intellisense.  And if necessary download and build third-party
> libraries
> not normally present on a Windows machine.  Most of this work is Windows
> specific
> and may not yet be upstream.   See GfW [1] and VCPKG [2].
>
> The synthesized solution and project files are automatically generated, so
> we
> do not have to separately track changes in the Makefile to the various file
> lists.
> These should be treated as read-only and re-generated in response to changes
> in
> the Makefile.  Using the solution/project files, we can completely build Git
> in
> the IDE or a command prompt and without the SDK.  This further simplifies
> things
> for Windows developers.
>
> So given that, I don't see a need to replace the main Makefile on Windows.
>
> Sorry,
> Jeff
>
> [1] https://github.com/git-for-windows/git
> [2] https://github.com/Microsoft/vcpkg