On Wed, May 13, 2020 at 2:29 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> "Sibi Siddharthan via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>
> > To make this a little less awkward, the Git for Windows project offers
> > the `vs/master` branch which has a full Visual Studio solution generated
> > and committed. This branch can therefore be used to tinker with Git in
> > Visual Studio _without_ having to download the full Git for Windows SDK.
> > Unfortunatly, that branch is auto-generated from Git for Windows'
> > `master`. If a developer wants to tinker, say, with `pu`, they are out
> > of luck.
>
> 'pu' or 'next' are not to be built upon, so this is not a good line
> of reasoning to complain that generating only for 'master' is bad.
>
> > CMake was invented to make this sort of problem go away, by providing a
> > more standardized, cross-platform way to configure builds.
>
> I think everything above this point (including Makefile, autoconf
> etc.) can be replaced with a single sentence
>
> The build infrastructure for Git is written around being
> able to run make, which is not supported natively on
> Windows.
>
> without anything else. That will flow naturally to
>
> Add a build script that uses CMake to help developers on
> Windows to build git.
>
> and then you can continue the current state, like this paragraph.
>
> > This is only the first step, and to make it easier to review, it only
> > allows for configuring builds on the platform that is easiest to
> > configure for: Linux.
> >
> > The CMake script checks whether the headers are present(eg. libgen.h),
> > whether the functions are present(eg. memmem), whether the funtions work
> > properly (eg. snprintf) and generate the required compile definitions
> > for the platform. The script also searches for the required libraries,
> > if it fails to find the required libraries the respective executables
> > won't be built.(eg. If libcurl is not found then git-remote-http won't
> > be built). This will help building Git easier.
> >
> > With a CMake script an out of source build of git is possible resulting
> > in a clean source tree.
>
>
> > Note: earlier endeavors on the Git mailing list to introduce CMake ended
> > up in dead water. The primary reason for that was that reviewers
> > _expected_ CMake support to fall out of maintenance, unless the
> > contributor would promise to keep an eye on keeping CMake support up to
> > date. However, in the meantime, support for automated testing has been
> > introduced in Git's source code, and a later patch will modify the
> > (still experimental) GitHub workflow to continually verify that CMake
> > support is still complete. That will make maintenance reasonably easy.
>
> I am not sure this belongs to the log message.
>
Will remove it.
> > Note: this patch asks for the minimum version v3.14 of CMake (which is
> > not all that old as of time of writing) because that is the first
> > version to offer a platform-independent way to generate hardlinks as
> > part of the build. This is needed to generate all those hardlinks for
> > the built-in commands of Git.
>
> This does, but I do not think hardlinks are not required for our
> build. On Unix filesystems, it is not just possible but convenient
> to use, and that is the only reason why we use hardlinks.
>
> If hardlinks are possible but inconvenient to use on Windows, you
> shouldn't force your target audience to use it.
Another alternative is to use verbatim copies, but this increases the
size of the generated build artifacts considerably.
Hardlinks are not inconvenient on Windows, CMake 3.14 gives a cross
platform way of generating them.
>
> > Instructions to run CMake:
> >
> > cmake `relative-path-to-srcdir` -DCMAKE_BUILD_TYPE=Release
> >
> > Possible build configurations(-DCMAKE_BUILD_TYPE) with corresponding
> > compiler flags
> > Debug : -g
> > Release: -O3
> > RelWithDebInfo : -O2 -g
> > MinSizeRel : -Os
> > empty(default) :
> >
> > NOTE: -DCMAKE_BUILD_TYPE is optional
> >
> > This process generates a Makefile.
> > Then run `make` to build Git.
> >
> > NOTE: By default CMake uses Makefile as the build tool on Linux, to use
> > another tool say `ninja` add this to the command line when configuring.
> > `-G Ninja`
>
> I find it curious that from the instruction, the most important
> platform, the primary reason why we are reviewing this patch, is
> missing. Don't Windows folks need to be told how to run CMake to
> build?
The instructions are the same for any platform. Just like ./configure.
>
> In any case, all of the above "Instructions" should go at the top
> part of CMakeLists.txt in a comment, and not in the log message.
> "git log" output is not an easy way for your target audience to
> learn how to use what the commit adds. Think what they need to do
> when they discover there is CMakeLists.txt in our tree in three
> months. Don't force them to run "git blame" to find this commit
> that added the support.
Okay, will add some instructions on top of the script.
>
> > Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@xxxxxxxxx>
> > ---
> > CMakeLists.txt | 528 +++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 528 insertions(+)
> > create mode 100644 CMakeLists.txt
> >
> > diff --git a/CMakeLists.txt b/CMakeLists.txt
> > new file mode 100644
> > index 00000000000..73703bd321f
> > --- /dev/null
> > +++ b/CMakeLists.txt
> > @@ -0,0 +1,528 @@
> > +#
> > +# Copyright (c) 2020 Sibi Siddharthan
> > +#
> > +
> > +cmake_minimum_required(VERSION 3.14)
> > +
> > +#Parse GIT-VERSION-GEN to get the version
> > +file(STRINGS ${CMAKE_SOURCE_DIR}/GIT-VERSION-GEN git_version REGEX "DEF_VER=v(.*)")
> > +string(REPLACE "DEF_VER=v" "" git_version ${git_version})
> > +string(REPLACE ".GIT" ".0" git_version ${git_version})#for building from a snapshot
>
> Hmph, I'd really prefer to see the logic in GIT-VERSION-GEN not
> bypassed like this. People know they can create a text file 'version'
> and record the version name they desire in it and expect GIT-VERSION-GEN
> to pick it up, for example.
>
> Later in this file, you seem to depend on the shell to do things
> like generating config-list.h file, so I'd rather see the same
> technique used here a well.
>
> > +set(libgit_SOURCES
> > + abspath.c add-interactive.c add-patch.c advice.c alias.c
> > +...
> > + zlib.c)
>
> Hmph.
>
> > +set(git_SOURCES
> > + builtin/add.c builtin/am.c builtin/annotate.c builtin/apply.c
> > + builtin/archive.c builtin/bisect--helper.c builtin/blame.c
> > + builtin/branch.c builtin/bundle.c builtin/cat-file.c builtin/check-attr.c
> > + builtin/check-ignore.c builtin/check-mailmap.c builtin/check-ref-format.c
> > + builtin/checkout-index.c builtin/checkout.c builtin/clean.c
> > + builtin/clone.c builtin/column.c builtin/commit-tree.c
> > + builtin/commit.c builtin/commit-graph.c builtin/config.c
> > + builtin/count-objects.c builtin/credential.c builtin/describe.c
> > + builtin/diff-files.c builtin/diff-index.c builtin/diff-tree.c
> > + builtin/diff.c builtin/difftool.c builtin/env--helper.c
> > + builtin/fast-export.c builtin/fetch-pack.c builtin/fetch.c builtin/fmt-merge-msg.c
> > + builtin/for-each-ref.c builtin/fsck.c builtin/gc.c
> > + builtin/get-tar-commit-id.c builtin/grep.c builtin/hash-object.c
> > + builtin/help.c builtin/index-pack.c builtin/init-db.c
> > + builtin/interpret-trailers.c builtin/log.c builtin/ls-files.c
> > + builtin/ls-remote.c builtin/ls-tree.c builtin/mailinfo.c builtin/mailsplit.c
> > + builtin/merge.c builtin/merge-base.c builtin/merge-file.c builtin/merge-index.c
> > + builtin/merge-ours.c builtin/merge-recursive.c builtin/merge-tree.c
> > + builtin/mktag.c builtin/mktree.c builtin/multi-pack-index.c builtin/mv.c
> > + builtin/name-rev.c builtin/notes.c builtin/pack-objects.c builtin/pack-redundant.c
> > + builtin/pack-refs.c builtin/patch-id.c builtin/prune-packed.c builtin/prune.c
> > + builtin/pull.c builtin/push.c builtin/range-diff.c builtin/read-tree.c
> > + builtin/rebase.c builtin/receive-pack.c builtin/reflog.c builtin/remote.c
> > + builtin/remote-ext.c builtin/remote-fd.c builtin/repack.c builtin/replace.c
> > + builtin/rerere.c builtin/reset.c builtin/rev-list.c builtin/rev-parse.c
> > + builtin/revert.c builtin/rm.c builtin/send-pack.c builtin/shortlog.c
> > + builtin/show-branch.c builtin/show-index.c builtin/show-ref.c
> > + builtin/sparse-checkout.c builtin/stash.c builtin/stripspace.c
> > + builtin/submodule--helper.c builtin/symbolic-ref.c builtin/tag.c
> > + builtin/unpack-file.c builtin/unpack-objects.c builtin/update-index.c
> > + builtin/update-ref.c builtin/update-server-info.c builtin/upload-archive.c
> > + builtin/upload-pack.c builtin/var.c builtin/verify-commit.c builtin/verify-pack.c
> > + builtin/verify-tag.c builtin/worktree.c builtin/write-tree.c)
>
> Can't we do a bit better here?
>
> Perhaps grab this out of our Makefile? The same command applies to
> huge lists of sources we have seen.
>
> Or do the equivalent of $(wildcard builtin/*.c) if CMake has such a
> feature?
>
We do have that.
> > ...
> > \ No newline at end of file
>
> Double check and make sure you have a text file without an incomplete
> line at the end.
>
> Thanks.
Thank You,
Sibi Siddharthan
