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

[Isaac Hier]

Yes I think I mentioned earlier that I have it hosted at
https://github.com/isaachier/git. I have been busy with a few things
so have not continued much since I started this conversation, but it
covers a large part of the Makefile if not all the significant
portions.

On Tue, Feb 20, 2018 at 11:28 AM, Robert Dailey
 wrote:
> On Thu, Jan 25, 2018 at 6:21 PM, Isaac Hier  wrote:
>> Hi Jeff,
>>
>> I have been looking at the build generator, which looks promising, but
>> I have one concern. Assuming I can generate a CMakeLists.txt that
>> appropriately updates the library sources, etc. how do you suggest I
>> handle new portability macros? For example, assume someone adds a
>> macro HAVE_X to indicate the availability of some platform-specific
>> function x. In the current Makefile, a comment would be added to the
>> top indicating when HAVE_X or NO_X should be set, and that option
>> would toggle the HAVE_X C macro. But CMake can test for the
>> availability of x, which is one of the main motives for adding a CMake
>> build. The current build generator uses the output of make, so all it
>> would know is whether or not HAVE_X is defined on the platform that
>> ran the Makefile, but not the entire list of platform that git
>> supports.
>>
>> Bottom line: should I add the portability tests as they are now,
>> without accounting for future portability macros? One good alternative
>> might be to suggest the authors of new portability macros include a
>> small sample C program to test it. That would allow me to easily patch
>> the CMake tests whenever that came up. In a best case scenario, a
>> practice could be established to write the test in a specific
>> directory with a certain name so that I could automatically update the
>> CMake tests from the build generator.
>
> Isaac,
>
> I'm very happy that you have started support for CMake. I have a lot
> of experience with it. I'd love to help contribute. Do you have a fork
> on github where this code is? I'd have to figure out how to apply a
> patch from email, I haven't done it before. I think the goal should be
> to replace the existing build system (this can be a transition that
> happens slowly). I've been in situations where multiple build systems
> are supported in parallel, worst case because of split personal
> preferences on a project. That is more counterproductive than asking
> the team to just compromise and take the initial hit on learning
> curve. Ultimately that's up to the Git community, but that would be my
> recommendation. But I think making CMake as complete as possible will
> help build that confidence and trust. I can completely understand the
> complexities and concerns they have.

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

[Robert Dailey]

On Thu, Jan 25, 2018 at 6:21 PM, Isaac Hier  wrote:
> Hi Jeff,
>
> I have been looking at the build generator, which looks promising, but
> I have one concern. Assuming I can generate a CMakeLists.txt that
> appropriately updates the library sources, etc. how do you suggest I
> handle new portability macros? For example, assume someone adds a
> macro HAVE_X to indicate the availability of some platform-specific
> function x. In the current Makefile, a comment would be added to the
> top indicating when HAVE_X or NO_X should be set, and that option
> would toggle the HAVE_X C macro. But CMake can test for the
> availability of x, which is one of the main motives for adding a CMake
> build. The current build generator uses the output of make, so all it
> would know is whether or not HAVE_X is defined on the platform that
> ran the Makefile, but not the entire list of platform that git
> supports.
>
> Bottom line: should I add the portability tests as they are now,
> without accounting for future portability macros? One good alternative
> might be to suggest the authors of new portability macros include a
> small sample C program to test it. That would allow me to easily patch
> the CMake tests whenever that came up. In a best case scenario, a
> practice could be established to write the test in a specific
> directory with a certain name so that I could automatically update the
> CMake tests from the build generator.

Isaac,

I'm very happy that you have started support for CMake. I have a lot
of experience with it. I'd love to help contribute. Do you have a fork
on github where this code is? I'd have to figure out how to apply a
patch from email, I haven't done it before. I think the goal should be
to replace the existing build system (this can be a transition that
happens slowly). I've been in situations where multiple build systems
are supported in parallel, worst case because of split personal
preferences on a project. That is more counterproductive than asking
the team to just compromise and take the initial hit on learning
curve. Ultimately that's up to the Git community, but that would be my
recommendation. But I think making CMake as complete as possible will
help build that confidence and trust. I can completely understand the
complexities and concerns they have.

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

[Jeff Hostetler]

On 1/25/2018 7:21 PM, Isaac Hier wrote:

Hi Jeff,

I have been looking at the build generator, which looks promising, but
I have one concern. Assuming I can generate a CMakeLists.txt that
appropriately updates the library sources, etc. how do you suggest I
handle new portability macros? For example, assume someone adds a
macro HAVE_X to indicate the availability of some platform-specific
function x. In the current Makefile, a comment would be added to the
top indicating when HAVE_X or NO_X should be set, and that option
would toggle the HAVE_X C macro. But CMake can test for the
availability of x, which is one of the main motives for adding a CMake
build. The current build generator uses the output of make, so all it
would know is whether or not HAVE_X is defined on the platform that
ran the Makefile, but not the entire list of platform that git
supports.

Bottom line: should I add the portability tests as they are now,
without accounting for future portability macros? One good alternative
might be to suggest the authors of new portability macros include a
small sample C program to test it. That would allow me to easily patch
the CMake tests whenever that came up. In a best case scenario, a
practice could be established to write the test in a specific
directory with a certain name so that I could automatically update the
CMake tests from the build generator.

Thanks for the help,

Isaac


It's been years since I've used cmake as anything other than
a casual (downstream) consumer, so I'm not sure I can answer
your questions.

The vcxproj target we have is a bit of a hack to automatically
capture the set of source files and target libraries and executables.
We don't try to capture the spirit of all of the HAVE_ and NO_ flags
when we build the *.vcxproj files.  And we make some assumptions in
the generation template for the usual VC/VS settings.  But then
Windows is a single target and we don't have to worry about some
things (like whether or not qsort is present).

I don't want to discourage you from attempting this.  (And I realize
that my initial response might have given that impression -- I mainly
wanted to say that we don't currently have a problem on Windows with
the current Makefile situation.)

A full cmake system would let us simplify some things, but it also
complicates some things.  So we might be trading one set of problems
for another.  For example, the libgit2 project uses cmake.  Not to
pick on them, but when I look at it, I see a lot of the same issues
(but perhaps with better syntax than the makefile).

https://github.com/libgit2/libgit2/blob/master/CMakeLists.txt

As to your portability test questions, I'm afraid I don't know.
Sorry,
Jeff

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

[Isaac Hier]

Hi Jeff,

I have been looking at the build generator, which looks promising, but
I have one concern. Assuming I can generate a CMakeLists.txt that
appropriately updates the library sources, etc. how do you suggest I
handle new portability macros? For example, assume someone adds a
macro HAVE_X to indicate the availability of some platform-specific
function x. In the current Makefile, a comment would be added to the
top indicating when HAVE_X or NO_X should be set, and that option
would toggle the HAVE_X C macro. But CMake can test for the
availability of x, which is one of the main motives for adding a CMake
build. The current build generator uses the output of make, so all it
would know is whether or not HAVE_X is defined on the platform that
ran the Makefile, but not the entire list of platform that git
supports.

Bottom line: should I add the portability tests as they are now,
without accounting for future portability macros? One good alternative
might be to suggest the authors of new portability macros include a
small sample C program to test it. That would allow me to easily patch
the CMake tests whenever that came up. In a best case scenario, a
practice could be established to write the test in a specific
directory with a certain name so that I could automatically update the
CMake tests from the build generator.

Thanks for the help,

Isaac

On Wed, Jan 24, 2018 at 4:00 PM, Jeff Hostetler  wrote:
>
>
> On 1/24/2018 2:59 PM, Isaac Hier wrote:
>>
>> 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.
>
> [...]
>>
>> 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
>
>
> Look at the "vcxproj:" target in config.mak.uname (in the GfW repo).
>
> Jeff

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

[Isaac Hier]

Stephan, I totally agree about the advanced options. At first, I left
them as visible options seeing as the Makefile does not comment which
are advanced and which are basic.

In terms of the up-to-dateness, I find it easier to "fast-forward" all
the changes at once without tangling myself in a load of periodic
updates.

On Wed, Jan 24, 2018 at 5:02 PM, Stephan Beyer  wrote:
> On 01/24/2018 10:19 PM, Isaac Hier wrote:
>> Thanks for your interest! This patch is based on the cmake-build
>> branch of https://github.com/isaachier/git, but the full history is on
>> the cmake branch (squashed it for easier readability). Hope that
>> helps.
>
> Thanks. I use the cmake branch because I prefer "real" history over one
> huge commit.
>
> And I already love it. Thanks for all the work!
>
> From a first short glance, I wonder if you should mark a lot more
> options as advanced options, like the paths (e.g., SHELL_PATH,
> LESS_PATH, GETTEXT_MSGFMT_EXECUTABLE, etc.) and probably also things
> like GIT_USER_AGENT. If you use a configuration tool like ccmake, you
> see a lot of options and many of them are not relevant to the average user.
>
> I also think some variables have weird names, for example, POLL, PREAD,
> MMAP should be USE_POLL, USE_PREAD, USE_MMAP, respectively... or even
> USE_*_SYSCALL, I don't know.
>
> By the way, regarding up-to-dateness, you are missing these recent
> changes that have been merged to master:
>
>   edb6a17c36 Makefile: NO_OPENSSL=1 should no longer imply BLK_SHA1=1
>   3f824e91c8 t/Makefile: introduce TEST_SHELL_PATH
>
> (which is not surprising)
>
> ~Stephan

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

[Stephan Beyer]

On 01/24/2018 10:19 PM, Isaac Hier wrote:
> Thanks for your interest! This patch is based on the cmake-build
> branch of https://github.com/isaachier/git, but the full history is on
> the cmake branch (squashed it for easier readability). Hope that
> helps.

Thanks. I use the cmake branch because I prefer "real" history over one
huge commit.

And I already love it. Thanks for all the work!

>From a first short glance, I wonder if you should mark a lot more
options as advanced options, like the paths (e.g., SHELL_PATH,
LESS_PATH, GETTEXT_MSGFMT_EXECUTABLE, etc.) and probably also things
like GIT_USER_AGENT. If you use a configuration tool like ccmake, you
see a lot of options and many of them are not relevant to the average user.

I also think some variables have weird names, for example, POLL, PREAD,
MMAP should be USE_POLL, USE_PREAD, USE_MMAP, respectively... or even
USE_*_SYSCALL, I don't know.

By the way, regarding up-to-dateness, you are missing these recent
changes that have been merged to master:

  edb6a17c36 Makefile: NO_OPENSSL=1 should no longer imply BLK_SHA1=1
  3f824e91c8 t/Makefile: introduce TEST_SHELL_PATH

(which is not surprising)

~Stephan

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

[Isaac Hier]

Thanks for your interest! This patch is based on the cmake-build
branch of https://github.com/isaachier/git, but the full history is on
the cmake branch (squashed it for easier readability). Hope that
helps.

On Wed, Jan 24, 2018 at 4:15 PM, Stephan Beyer  wrote:
> Hi Isaac,
>
> On 01/24/2018 02:45 PM, Isaac Hier wrote:
>> I realize this is a huge patch, but does anyone have feedback for the
>> general idea?
>
> Thank you very much. I am *personally* interested in this due to several
> reasons (which are mostly that I am used to CMake and when I do
> something on the Git codebase, I always end up that its build system
> recompiles everything ...which drives me crazy as hell. Using CMake, I
> could simply use out-of-source builds and be happy).
>
> I am not sure if it should go into the main Git repo. I'd already be
> happy if I could pull it from somewhere (github for example) and rebase
> it to use for my local branches.
>
> ~Stephan

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

[Isaac Hier]

CMake is very portable (see
https://open.cdash.org/index.php?project=CMake for details). About the
whole autoconf history in Git, I came across this post by Linus while
researching if anyone had done something with CMake in the git project
before:

> NO! At least the Makefile is debuggable and understandable.
>
> If we need a better build system, I'd much rather use something
> higher-level that can generate VC++ project files etc.
>
> In other words, I'd much rather see us using CMake or something like that,
> which actually adds real value-add.
>
> (And no, I've never used cmake, so maybe it has horrors waiting for us
> too, but autoconf is just worthless).
>
> Linus

https://marc.info/?l=git=115032515024816=2

On Wed, Jan 24, 2018 at 4:00 PM, Jeff Hostetler  wrote:
>
>
> On 1/24/2018 2:59 PM, Isaac Hier wrote:
>>
>> 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.
>
> [...]
>>
>> 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
>
>
> Look at the "vcxproj:" target in config.mak.uname (in the GfW repo).
>
> Jeff

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

[Stephan Beyer]

Hi Isaac,

On 01/24/2018 02:45 PM, Isaac Hier wrote:
> I realize this is a huge patch, but does anyone have feedback for the
> general idea?

Thank you very much. I am *personally* interested in this due to several
reasons (which are mostly that I am used to CMake and when I do
something on the Git codebase, I always end up that its build system
recompiles everything ...which drives me crazy as hell. Using CMake, I
could simply use out-of-source builds and be happy).

I am not sure if it should go into the main Git repo. I'd already be
happy if I could pull it from somewhere (github for example) and rebase
it to use for my local branches.

~Stephan

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

[Jeff Hostetler]

On 1/24/2018 2:59 PM, Isaac Hier wrote:

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.

[...]

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


Look at the "vcxproj:" target in config.mak.uname (in the GfW repo).

Jeff

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

[Ævar Arnfjörð Bjarmason]

On Wed, Jan 24 2018, Junio C. Hamano jotted:

> Isaac Hier  writes:
>
>> I realize this is a huge patch, but does anyone have feedback for the
>> general idea?
>
> I personally am not interested, especially with the justification
> given in the cover letter.
>
> Perhaps the one in this patch may be "mostly complete", and I am
> sure you can make it "complete" against a frozen target, but it is
> unclear to me how you envision keeping the completeness up to date.
>
> Whenever a developer needs to introduce a new build knob, the
> support for it needs to be implemented in not just Makefile but now
> also in this other thing.  Unless there is an automated
> bi-directional gateway to allow those who have been writing and
> reading Makefile not to worry about those who wants to build with
> CMake, and vice versa, you are forcing everybody to do the same work
> twice, no?
>
> Choice of build procedure for a project is like choise of SCM to
> store its source file.  If the new system is 10x better to make it
> worthwhile to educate everybody to use it, switching to a new system
> and ditching the current one *is* a reasonable thing to propose and
> consider.
>
> But I do not think you are proposing to switch, and I do not think
> you are convincingly arguing that it is 10x better than the current
> one, either.

There's more than 400 lines of instructions at the top of our current
Makfile. Most of that is of the form "if your system has/doesn't have
so-and-so, define so-and-so".

For whatever reason we've decided not to make autoconf a hard
dependency. I don't know/remember what those reasons are, but if we
could get *some* build system that could use compilation results to
drive its build that would be worth it.

I don't know if cmake is that system, i.e. if we could waive a magic
wand and replace our current build system with it whether we'd still
need a fallback Makefile on some platforms. Is it as portable as GNU
autoconf & make? I don't know.

It would be very nice if git's build system wouldn't require patches
like my fb95e2e38d ("grep: un-break building with PCRE >= 8.32 without
--enable-jit", 2017-06-01), which is only needed because we don't have a
way to run a small C program to determine what the value of something
like NO_LIBPCRE1_JIT should be.

Well, we have it *optionally* with autoconf, but as long as it's
optional we don't save ourselves any time, and from packages I've seen
in the wild most people who build git don't use it, so it wouldn't save
them any time either.

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

[Isaac Hier]

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  wrote:
>
>
> 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

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

[Jeff Hostetler]

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

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

[Junio C Hamano]

Isaac Hier  writes:

> I realize this is a huge patch, but does anyone have feedback for the
> general idea?

I personally am not interested, especially with the justification
given in the cover letter.

Perhaps the one in this patch may be "mostly complete", and I am
sure you can make it "complete" against a frozen target, but it is
unclear to me how you envision keeping the completeness up to date.

Whenever a developer needs to introduce a new build knob, the
support for it needs to be implemented in not just Makefile but now
also in this other thing.  Unless there is an automated
bi-directional gateway to allow those who have been writing and
reading Makefile not to worry about those who wants to build with
CMake, and vice versa, you are forcing everybody to do the same work
twice, no?

Choice of build procedure for a project is like choise of SCM to
store its source file.  If the new system is 10x better to make it
worthwhile to educate everybody to use it, switching to a new system
and ditching the current one *is* a reasonable thing to propose and
consider.

But I do not think you are proposing to switch, and I do not think
you are convincingly arguing that it is 10x better than the current
one, either.  

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

[Jacob Keller]

On Wed, Jan 24, 2018 at 5:45 AM, Isaac Hier  wrote:
> I realize this is a huge patch, but does anyone have feedback for the
> general idea?
>

I don't know anything about CMake so I can't comment on the patch
itself. Having additional build systems does not bother me, but it
does mean that someone has to maintain the build system and try to
keep it in sync with changes that occur to the main one in use. That
can be problematic.

Personally, if we added a new build system, I think I'd prefer
something like meson with ninja, but that's only because of the
examples I've seen where build times were improved significantly. I
have no idea what advantages CMake would give on this front.

Thanks,
Jake

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

[Isaac Hier]

I realize this is a huge patch, but does anyone have feedback for the
general idea?

On Mon, Jan 22, 2018 at 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.
>
> Isaac Hier (1):
>   Implement CMake build
>
>  CMakeLists.txt  | 1849 
> +++
>  cmake/GenerateCmdlist.cmake |   83 ++
>  cmake/fopen_dir_test.c  |   11 +
>  cmake/fstat_test.c  |   37 +
>  cmake/gmtime_test.c |7 +
>  cmake/iconv_test.c  |   13 +
>  cmake/inline_test.c |9 +
>  cmake/mkdir_test.c  |7 +
>  cmake/mmap_test.c   |   35 +
>  cmake/parens_test.c |6 +
>  cmake/snprintf_test.c   |7 +
>  cmake/sysctl_test.c |   11 +
>  12 files changed, 2075 insertions(+)
>  create mode 100644 CMakeLists.txt
>  create mode 100644 cmake/GenerateCmdlist.cmake
>  create mode 100644 cmake/fopen_dir_test.c
>  create mode 100644 cmake/fstat_test.c
>  create mode 100644 cmake/gmtime_test.c
>  create mode 100644 cmake/iconv_test.c
>  create mode 100644 cmake/inline_test.c
>  create mode 100644 cmake/mkdir_test.c
>  create mode 100644 cmake/mmap_test.c
>  create mode 100644 cmake/parens_test.c
>  create mode 100644 cmake/snprintf_test.c
>  create mode 100644 cmake/sysctl_test.c
>
> --
> 2.14.1
>